From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Pipe to sendmail (again)
Date: 14 Jul 2000 12:28:25 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 53
Message-ID: <8kn119$fcg$1@nets3.rz.RWTH-Aachen.DE>
References: <yG3a5.322335$k22 DOT 1427482 AT flipper> <56ga5.329089$k22 DOT 1448044 AT flipper> <8kcu4s$juv$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <200007130406 DOT AAA24310 AT envy DOT delorie DOT com> <8kkki9$gcv$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE> <200007131819 DOT OAA25496 AT envy DOT delorie DOT com>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 963577705 15760 137.226.32.75 (14 Jul 2000 12:28:25 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 14 Jul 2000 12:28:25 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

DJ Delorie <dj AT delorie DOT com> wrote:

> I'm telling you what *is*, not what *should be*.

Point taken.

>> In my not so humble opinion, '_fmode' is one of the silliest things
>> DOS compilers ever came up with.

> Perhaps, but it is quite handy to have around.

I agree it feels like a handy tool at first glance. But in the long
run it causes about as many new problems as it was originally supposed
to solve, I think.  Making a correct, portable ANSI C program source
unportable to other compilers or platforms should really be avoided,
if the same effect can be reached by standardized means.

>> > In cygwin, the "default" comes from the mount table, and is often
>> > "binary", so the "t" is a good idea.
>> 
>> I oppose to this view. The only truly good idea is to fix the programs
>> on source level.

> You're thinking the wrong way.  What I do is mount all my NT local
> drives as text, and my unix/samba drives as binary.  That way, when I
> redirect to the unix drives, everything saves the files in unix text
> format.

OK, let me play the advocatus diaboli for a while. So we have a
'typical' Unix source, where all fopen()s are in default mode (no 'b',
no 't'), same for the open() calls, if any. It's been compiled as-is
on Cygwin, reading/writing files in two filesystems, one of which is
mounted as 'text', the other as 'binary'. Now, as long as this program
really writes text files, everything should work nicely, as stated.

But what if it starts to operate on some files meant to be binary,
too? Remember: there are no "rb" or "wb" modes in this code. I.e. the
default _fmode from the mount table will take over, and they'll
suddenly be written in text mode, on the 'text' mounted filesystem,
causing the program to stop doing any useful work, most probably.

Of course, there will usually be some machinery that tries to
automatically detect whether a file is a text or a binary file in the
filesystem driver, to avoid this problem. But this machinery *will*
guess wrong, from time to time, and I wouldn't want to be within reach
of any user the moment he discovers _that_ as the reason for some
program to stubbornly refuse working, after a week of debugging...

To summarize, _fmode, and the 't' mode specifier made necessary by it,
are driving out Baal by Beelzebub.
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.