Re: RFA: Ignore DOS end-of-line characters (ctrl-Z) unless -W

[Zack Weinberg <zack at codesourcery dot com>]

On Wed, May 08, 2002 at 09:59:38PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 8 May 2002 08:33:38 -0700
> > From: Zack Weinberg <zack@codesourcery.com>
> > 
> > > For other systems, I guess a warning under -W is okay.
> > 
> > With or without truncating the input file?
> 
> Without, I guess: on any other system, you cannot be sure that the
> file with a ^Z came from a DOSish platform.  I expect Unix and
> GNU/Linux users outcry if/when they find out that a ^Z causes GCC to
> stop reading.

As it is, ^Z in a file will produce a hard error, so I doubt anyone is
relying on the preprocessor not stopping.

Perhaps we could make the warning on by default if (a) the system is
Unix-y, (b) there is other text after the ^Z (besides more ^Z-s).
That should prevent user confusion.

> There's no relation between ^Z and newlines whatsoever.  Old DOS
> editors could put a ^Z anywhere, including several ^Zs one after
> another.

Do they ever insert a ^Z in the middle of a file in order to truncate
it, and not bother to update the filesystem's idea of the file size?
(This is the only way I can think of that there would be a ^Z with a
bunch of text after it, when the file is transferred to a system that
ignores ^Z.)

> > It makes no distinction.  What goes wrong when one reads from a
> > terminal in binary mode under DOS?
> 
> You don't have echo, and you cannot easily stop the input (because ^Z
> is no longer special to the system calls, and because binary input is
> not line-buffered, so many characters are needed before the program
> actually sees the ^Z).

Oh, I get it: on a terminal, "binary mode" is what Unix calls "raw
mode". Yeah, we should not set binary mode on terminals under DOS.  Do
you think we should worry about that for anything other than standard
input (e.g. "cpp con:")

> > (I'm not sure how to open a file in text mode using open(),
> > incidentally)
> 
> Either O_TEXT in `open' or "rt" in `fopen'.  (I hope I understood the
> question, since I think you already know that.)

That's what I was asking.  There isn't any such thing as O_TEXT in
Unix land, you see.  And cppfiles.c has been written on the assumption
that open/close/read are the lowest-level interface available, without
any libraries doing uncontrollable translation operations in betwteen.
This is not true except on Unix.

I would like to get patches that made cppfiles.c use whatever
interface is closest to the bare metal on all supported operating
systems.  (Short of bypassing the filesystem and reading raw disk
devices, of course. :-)

zw