[in regard to using "rt" as the mode parameter to fopen, i.e.,
fp = fopen(name, "rt");
]

>Bill Reid wrote:
>>... With many compilers, [if using just "r" instead of "rt",] I
>>might wind up opening the file as "binary" (now THAT'S scary!)...

In article <HOb4j.1226$t31.668@trnddc02>
James Kuyper <jameskuyper@verizon.net> wrote:
>I know of compilers where text streams and binary streams behave in
>exactly the same fashion (which is permitted). This is the norm for most
>of the systems I've ever used; I've only seen them behave differently on
>DOS/Windows machines, which I've rarely worked on.
>
>Do you know of an implementation which has text streams which behave
>differently from binary streams, where opening a text stream requires a
>'t' in the mode string? If so, it's non-conforming.

There *are* some such systems (for MS-DOS and/or Windows). I try
to avoid DOS/Windows as much as possible, so I am not sure which
ones. It is, however, my understanding that in order to get the
"bad" behavior on these systems, which one then must use "rt" to
override, one has to first use some *other* undefined behavior.
For instance, consider the following hypothetical C code (with some
parts removed for simplicity):

#include <stdio.h>
#include <nonstandard-io.h>

int main(void) {
FILE *fp1, *fp2;

SetDefaultFOpenMode("binary");
fp1 = fopen("foo", "r"); /* same as "rb" */
fp2 = fopen("bar", "rt"); /* same as "r" */
... process the files, provided fp1 and fp2 are non-NULL ...
return 0;
}

We can transform the above into a strictly conforming program,
which will work on *all* implementations -- not just the $10,000-
per-day Frobozz C Compiler -- simply by *removing* two lines and
using the appropriate mode parameters:

#include <stdio.h>

int main(void) {
FILE *fp1, *fp2;

fp1 = fopen("foo", "rb");
fp2 = fopen("bar", "r");
... process the files, provided fp1 and fp2 are non-NULL ...
return 0;
}

It always seemed to me that anyone who thought about the issue for
even a few seconds would choose the second (portable) version.
For some reason, however, many DOS/Windows programmers seem to
prefer to lock themselves in to compilers like the Frobozz C
Compiler, instead of writing less code that works everywhere. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

....didn't see this old post till now, so I'll repsond even though most
of the thread participants have passed away...

Chris Torek <nospam@torek.net> wrote in message
news:fiur980222v@news3.newsguy.com...
> [in regard to using "rt" as the mode parameter to fopen, i.e.,
> fp = fopen(name, "rt");
> ]
>
> >Bill Reid wrote:
> >>... With many compilers, [if using just "r" instead of "rt",] I
> >>might wind up opening the file as "binary" (now THAT'S scary!)...
>
> In article <HOb4j.1226$t31.668@trnddc02>
> James Kuyper <jameskuyper@verizon.net> wrote:
> >I know of compilers where text streams and binary streams behave in
> >exactly the same fashion (which is permitted). This is the norm for most
> >of the systems I've ever used; I've only seen them behave differently on
> >DOS/Windows machines, which I've rarely worked on.
> >
> >Do you know of an implementation which has text streams which behave
> >differently from binary streams, where opening a text stream requires a
> >'t' in the mode string? If so, it's non-conforming.
>
> There *are* some such systems (for MS-DOS and/or Windows). I try
> to avoid DOS/Windows as much as possible, so I am not sure which
> ones. It is, however, my understanding that in order to get the
> "bad" behavior on these systems, which one then must use "rt" to
> override, one has to first use some *other* undefined behavior.
> For instance, consider the following hypothetical C code (with some
> parts removed for simplicity):
>
> #include <stdio.h>
> #include <nonstandard-io.h>
>
> int main(void) {
> FILE *fp1, *fp2;
>
> SetDefaultFOpenMode("binary");
> fp1 = fopen("foo", "r"); /* same as "rb" */
> fp2 = fopen("bar", "rt"); /* same as "r" */
> ... process the files, provided fp1 and fp2 are non-NULL ...
> return 0;
> }

Not exactly. The "implementation" COULD (MIGHT, MAYBE) have
set the default file opening mode to "O_BINARY"...this is classic FUD
about "portability". Are there any "implementations" out there that
set the file opening default mode to binary? Or has anybody else
done it in a library header? Probably not, BUT WHO KNOWS????

> We can transform the above into a strictly conforming program,
> which will work on *all* implementations -- not just the $10,000-
> per-day Frobozz C Compiler -- simply by *removing* two lines and
> using the appropriate mode parameters:
>
> #include <stdio.h>
>
> int main(void) {
> FILE *fp1, *fp2;
>
> fp1 = fopen("foo", "rb");
> fp2 = fopen("bar", "r");
> ... process the files, provided fp1 and fp2 are non-NULL ...
> return 0;
> }

Actually, the COMPLETELY "portable" fix is to set the mode to
"O_TEXT" affirmatively regardless of any settings by any other
entity in a little __DOSWIN__ ifdef'd "portability library" for your
PERFECTLY "portable" code base...otherwise, you MIGHT
have problems on other DOS/Windows compilers or foreign
library headers...

> It always seemed to me that anyone who thought about the issue for
> even a few seconds would choose the second (portable) version.
> For some reason, however, many DOS/Windows programmers seem to
> prefer to lock themselves in to compilers like the Frobozz C
> Compiler, instead of writing less code that works everywhere. :-)

The goal of just about all software companies is to lock you
into THEIR proprietary software, otherwise they couldn't make
a profit, and one of the primary tools of psychological warfare
they use to accomplish this is FUD...which, if you think about
the issue for even a few seconds, is EXACTLY the same method
used by people who are overly-concerned about "portability",
and to be even more antagonizing, people who advocate (for
money, of course) the replacement of perfectly fine working
software with untested, potentially very buggy, "open source"...

The net result of all this behavior, of course, is that it takes
more people more money now to store and retrieve the "Jenkins
report" than it did in the 1930s, and that's the way "we" like
it, isn't it?

---
William Ernest Reid

[I shall not be reading any reply that Bill Reid might make to this
article. Those who remember what happened last time I posted corrections
to his nonsense will understand why.]

Bill Reid said:

>
> ...didn't see this old post till now, so I'll repsond even though most
> of the thread participants have passed away...

Why?

> Chris Torek <nospam@torek.net> wrote in message
> news:fiur980222v@news3.newsguy.com...
>> [in regard to using "rt" as the mode parameter to fopen, i.e.,
>> fp = fopen(name, "rt");
>> ]
>>
>> >Bill Reid wrote:
>> >>... With many compilers, [if using just "r" instead of "rt",] I
>> >>might wind up opening the file as "binary" (now THAT'S scary!)...

No, it's not scary, just wrong. If you open using "rt" the behaviour is
undefined, whereas if you open using "r" and the call succeeds, the stream
is *required* to be open in text mode.

<snip>

> The "implementation" COULD (MIGHT, MAYBE) have
> set the default file opening mode to "O_BINARY"...this is classic FUD
> about "portability".

No, the implementation is required to translate fopen calls correctly, or
it isn't a conforming implementation. No conforming implementations behave
in the way you describe.

> Are there any "implementations" out there that
> set the file opening default mode to binary?

There isn't a "default" file opening mode. "r" is text mode, and "rb" is
binary mode". "r+" is text mode, and "r+b" is binary mode. And so on.

<snip>

> Actually, the COMPLETELY "portable" fix is to set the mode to
> "O_TEXT" affirmatively regardless of any settings by any other
> entity in a little __DOSWIN__ ifdef'd "portability library" for your
> PERFECTLY "portable" code base...otherwise, you MIGHT
> have problems on other DOS/Windows compilers or foreign
> library headers...

There is no need for such a "fix", and to introduce one sounds error-prone
and confusing.

<snip>

> The goal of just about all software companies is to lock you
> into THEIR proprietary software,

Then it's just as well that the Standard imposes particular behaviour on
all conforming implementations.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

In article <L-mdna2lvdNUL2banZ2dnUVZ8umdnZ2d@bt.com>,
Richard Heathfield <rjh@see.sig.invalid> wrote:
>[I shall not be reading any reply that Bill Reid might make to this
>article. Those who remember what happened last time I posted corrections
>to his nonsense will understand why.]
>
>Bill Reid said:
>
>>
>> ...didn't see this old post till now, so I'll repsond even though most
>> of the thread participants have passed away...

Note that threads are off-topic here (this point is made about 3 or 4
times a day), so this discussion ought to have ended right here. Why
Heathfield responded, I cannot fathom.

"Little Dick" comes up with the perfect troll! Watch the "master
baiter" at work...

Richard Heathfield <rjh@see.sig.invalid> wrote in message
news:L-mdna2lvdNUL2banZ2dnUVZ8umdnZ2d@bt.com...

> I shall not be reading any reply that Bill Reid might make to this
> article.

What, and miss out on the response to your troll? Me thinks
you WILL read my reply, but shan't have a response any more
idiotic or incorrect than the troll-drivel you just wrote, so why
try to improve on "perfection"...

> Those who remember what happened last time I posted corrections
> to his nonsense will understand why.

Well, first they'd have read your tortured mind to determine exactly
when and what you mean by you "posted corrections to his nonsense",
since I'm not sure that has ever happened...however, as a memory
aid, I guess you just are talking about the last time you trolled me,
and then a few days later admitted by contradicting your own "corrections"
that it was all just a troll...

> Bill Reid said:
>
> > Are there any "implementations" out there that
> > set the file opening default mode to binary?
>
> There isn't a "default" file opening mode. "r" is text mode, and "rb" is
> binary mode". "r+" is text mode, and "r+b" is binary mode. And so on.

BWHAHAHAHAHAHAHAHAHAHA!!!!

I think you're just a troll, but as I've said before, there is a very fine
line between acting like a fool and actually being one, and you do have
to question where the troll instinct comes from (it's a reasonable
theory that people who are just a little too stupid to contribute to society
fully just degenerate into trollery as a "lifestyle"):

_fmode

Syntax

extern int _fmode;

Header File

fcntl.h

Description

_fmode determines in which mode (text or binary) files will be opened and
translated. The value of _fmode is O_TEXT by default, which specifies that
files will be read in text mode. If _fmode is set to O_BINARY, the files are
opened and read in binary mode. (O_TEXT and O_BINARY are defined in
fcntl.h.)

---end of "implementation" documentation excerpt

Sounds like a "default file opening mode" to me, but to a TROLL,
"there isn't a 'default' file opening mode" (wonder how many days
we'll have to wait before he admits that many "implementations"
have a "default file opening mode"...and of course, by implication,
that he's just a worthless troll...

---
William Ernest Reid

In article <ufTKj.157130$cQ1.106304@bgtnsc04-news.ops.worldnet.att.net>
Bill Reid <hormelfree@happyhealthy.net> wrote:
>Syntax
>
>extern int _fmode;
>
>Header File
>
>fcntl.h
>
>Description
>
>_fmode determines in which mode (text or binary) files will be
>opened and translated. The value of _fmode is O_TEXT by default,
>which specifies that files will be read in text mode. If _fmode
>is set to O_BINARY, the files are opened and read in binary mode.
>(O_TEXT and O_BINARY are defined in fcntl.h.)

Use of "_fmode" makes your code "not Standard C": neither C89 nor
C99 have _fmode. (In fact, it is "even less standard" than that;
see below.) In other words, this "default mode" stuff is an
extension to the Standard.

If you write 100% Standard C, you will not use _fmode, nor <fcntl.h>.
As a result, _fmode will *stay* O_TEXT, and you will never need
"rt" as a parameter to fopen().

If you *do* use _fmode, your code will not compile on a number of
systems, which do not *have* _fmode. (This includes most Unix-like
systems, many of which *do* have <fcntl.h>, which is not a Standard
C header but is a POSIX header. POSIX does not specify an _fmode
in <fcntl.h>, nor O_TEXT and O_BINARY for that matter. See
<http://www.opengroup.org/onlinepubs/009695399/basedefs/fcntl.h.html>.)
So if you have a program that sets _fmode to O_BINARY, and then
uses "rt" to open its text files for reading, you can simply *remove*
the code that sets _fmode, and go back to using Standard C, and
the code will be both shorter *and* more portable.

Of course, making this change to the code may cause opening a binary
file with "r" or "w" not to work as desired, since those will also
now be opened in text mode. But why not fix the code to use "rb"
and "wb" mode strings for fopen() -- which must work on *any*
Standard C system, even the old C89 ones -- and stop using _fmode?
Then your code will work on this system that does provide _fmode,
and that other one that does not. (By "this system" I mean whichever
one Bill Reid is describing above. By "that other one" I mean
any POSIX-like system that has <fcntl.h> but not _fmode, or even
any system that supports C89 and/or C99 yet lacks <fcntl.h>
entirely.)

In other words, my advice is: "Avoid any non-Standard feature when
all it does is make your code longer and less portable. All you
have gained is that your code is less maintainable and harder to
move to a new platform. Use non-Standard features when they buy
you something that is worth the loss of portability." Extensions
that make your code less portable, with no gain in function or
maintainability, are worthless.[%]

This system's extension -- and by "this system" I again mean Bill
Reid's -- falls into this "worthless" category. Stop using it!
(By "it" I mean "the extension", not necessarily the system. :-) )

[% One can invent a scenario, perhaps involving a third party
library supplied only in binary form, in which one is forced to
use this particular extension. It then becomes "not worthless",
although had the system not provided the extension in the first
place, the third-party library would presumably have been coded
correctly in the first place, so that the extension would not be
required. In other words, its "worth" in this case is self-generated:
using the extension locks you into further use of the extension.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html