X-Authentication-Warning:	delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date:	Wed, 8 May 2002 13:23:17 -0700
From:	Zack Weinberg <zack AT codesourcery DOT com>
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Cc:	pavenis AT latnet DOT lv, nickc AT cambridge DOT redhat DOT com, djgpp-workers AT delorie DOT com,
	gcc-patches AT gcc DOT gnu DOT org
Subject:	Re: RFA: Ignore DOS end-of-line characters (ctrl-Z) unless -W
Message-ID:	<20020508202317.GI20829@codesourcery.com>
References:	<Pine DOT LNX DOT 4 DOT 21 DOT 0205081655590 DOT 26648-100000 AT gulbis DOT latnet DOT lv> <Pine DOT SUN DOT 3 DOT 91 DOT 1020508170644 DOT 25387K-100000 AT is> <20020508153338 DOT GE20829 AT codesourcery DOT com> <5832-Wed08May2002215938+0300-eliz AT is DOT elta DOT co DOT il>
Mime-Version:	1.0
In-Reply-To:	<5832-Wed08May2002215938+0300-eliz@is.elta.co.il>
User-Agent:	Mutt/1.3.28i
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie 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 AT codesourcery DOT 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

- Raw text -