«

"Bill Reid" <> writes:
> Keith Thompson <kst-> wrote in message
> news:...
[...]
>> Why do you insist on using scare-quotes for the word "standard"?
>
> For your information, those are "sarcastic quote marks", and I have
> an annoying habit of using them, and look, I just did it again...

Yes, I know what they are. The correct term for them is "scare
quotes" (not hyphenated, my mistake). And yes, it's annoying.

>> And
>> how is the standard contradictory?
>>
> It declares "non-standard" (whoops, did it again) function arguments
> as possibly causing errors because they could possibly open file types
> not intended by the programmer. This is some amazing circular logic
> that only a committee could cogitate...

Then you've failed to understand what the standard actually says.

[...]

>> There are *no* conforming C implementations on which using just "r"
>> rather than "rt" will cause a problem.
>
> So what's your point? My "implementation" DOES not only ALLOW
> it but REQUIRE it under certain circumstances...as a practical matter,
> what am I to do? Hold my breath until all the "non-conforming" compilers
> disappear retroactively?

If your statement is accurate, then you're using a non-conforming
implementation. I suggest you complain to your vendor. In the
meantime, if you're forced to write non-conforming code, I recommend
that you add comments explaining why you're doing so; otherwise, the
next person to maintain your code is likely to "fix" it.

[...]

>> Here's a clue. A simpler version of the phrase "technically correct"
>> is "correct". I can think of no reason to use "rt" rather than "r";
>> where "rt" is supported, it presumably does the same thing, and where
>> "rt" is not supported, using "r" is correct.
>
> Try reading what I actually wrote...carefully this time. With many
> compilers, I might wind up opening the file as "binary" (now THAT'S
> scary!)...

Can you tell me which implementations behave this way, so I can avoid
them?

--
Keith Thompson (The_Other_Keith) <kst->
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

CBFalconer wrote:
>
> pete wrote:
> > CBFalconer wrote:
> >
> ... snip ...
> >
> >> Try out ggets. It will handle ANY size line. I deliberately
> >> designed it to replace gets, with the usage simplicity, but no
> >> worry about over-run. It's primary use is in interactive work,
> >> but the efficiency is not bad for general use.
> >
> > The definition of fggets declares no size_t type objects!
> >
> > The cast in this expression in fggets, doesn't do anything:
> > realloc(buffer, (size_t)cursize))
>
> You didn't read it. cursize has been increased when this is
> encountered. The testing in the zipfile proves it. Oh, you mean
> the parameter. That is harmless. cursize should probably be a
> size_t anyhow.
>
> > I think that ggets.h:
> >
> > int fggets(char* *ln, FILE *f);
> > #define ggets(ln) fggets(ln, stdin)
> >
> > should also have this function declaration:
> >
> > int (ggets)(char* *ln);
>
> Why?

Just for kicks mostly.
That way you can both have the function and use the macro.

--
pete

Bill Reid wrote:
> Keith Thompson <kst-> wrote in message
> news:...
....
>> is "correct". I can think of no reason to use "rt" rather than "r";
>> where "rt" is supported, it presumably does the same thing, and where
>> "rt" is not supported, using "r" is correct.
>
> Try reading what I actually wrote...carefully this time. With many
> compilers, I might wind up opening the file as "binary" (now THAT'S
> scary!)...

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.

pete wrote:
>
> pete wrote:
>
> > /* BEGIN file_parse.c */
>
> I rewrote some of the code.

And then I decided to put it here:

http://www.mindspring.com/~pfilandr/...s/file_parse.c

--
pete

pete wrote:
> CBFalconer wrote:
>> pete wrote:
>>
.... snip ...
>>
>>> I think that ggets.h:
>>>
>>> int fggets(char* *ln, FILE *f);
>>> #define ggets(ln) fggets(ln, stdin)
>>>
>>> should also have this function declaration:
>>>
>>> int (ggets)(char* *ln);
>>
>> Why?
>
> Just for kicks mostly.
> That way you can both have the function and use the macro.

Why? All that will ever do is increase the code space used and
slow down the operation. Zero benefit. Max. nuisance.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.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 <> 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 <> wrote in message
news:...
> [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 <> 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

In article <L->,
Richard Heathfield <> 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 <> wrote in message
news:L-...

> 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
helpfully 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$>
Bill Reid <> 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