Subject: Re: ASCII and BINARY files. Why?
From: [email-masked] (Jim Balter)

2 Feb 1997 00:32:38 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Original-To: Fergus Henderson <[email-masked]>
Original-CC: gnu-win32 <[email-masked]>
Original-Sender: [email-masked]

Fergus Henderson wrote:

>           (^Z at the console should be EOF iff `stty eof ^Z'.)

What sort of implementation do you have in mind?  I suppose that
stty could store a registry entry that maps the tty state to the console
window somehow, and cygwin.dll would query the registry upon startup.
Pretty squirelly, but perhaps it could be made to work.  At the very
least there should be functioning termio[s] calls that work for the
current program.  Right now the terminal handling is botched, with
"binary" writes to console generating output CR's, a botch that makes
O_BINARY fail rather miserably.

> For example of the difference, in the C preprocessor,
> 
>         #define foo \<carriage return><newline>
>         bar
> 
> is different from
> 
>         #define foo \<newline>
>         bar
> 
> Now, in this particular case, it is implementation-defined what
> constitutes the end of a line, and so the GNU C preprocessor could
> define the end of a line as either "\r\n" or "\n".  However, the ANSI
> standard requires that the implementation document this choice, and so
> if this change were made, the documentation would need to be changed.

I challenge you to show me where the standard requires this.
Source files could be represented as tinkertoy structures, for all the
standard specifies.  File structure, like other matters such as
what command line flags the compiler honors, are beyond the scope of
the standard.

Of course, there is a "quality of implementation" issue, and an
implementation *ought to* specify such such things, but the standard
doesn't require it.  However, I'm quibbling; certainly the C compiler
is one of those programs I mentioned where the presence or absence
of a carriage return at the end of a line is significant.  But since I
already mentioned their existence, your providing one example doesn't do
much.  In any case, since \<cr> at the end of a line isn't syntactically
legal, it's a rather minor matter how the compiler treats it.

> Why do you think there would only be "a few" exceptions like this?

Because I spent 8 years developing unix tools.

> I think that cases like this are very common.

You've managed to name one, which is an extreme example because it
has an ANSI standard behind it, and even then the change in behavior,
which would allow certain unlikely programs that formerly were illegal
to become legal, is irrelevant and insignificant.

> So, I think the problem with your suggestion is that even though these
> changes might well be worthy enhancements, the sheer number of changes
> required would be overwhelming.

I offered a *path* to a goal.  The development of emacs, gcc, and the
entire GNU tools set was far far more "overwhelming"  than
what I suggested (which I don't think involves much work at all,
actually), and yet it was done by people who don't let themselves
be "overwhelmed". 

> 
> --
> Fergus Henderson <[email-masked]>   |  "I have always known that the pursuit
> WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
> PGP: finger [email-masked]         |     -- the last words of T. S. Garp.

Life itself is lethal; don't let that stand in your way.

--
<J Q B>
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".