Mail Archives: djgpp/2000/07/14/08:33:09
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.
- Raw text -