From: jqb AT netcom DOT com (Jim Balter) Subject: Re: ASCII and BINARY files. Why? 2 Feb 1997 00:32:38 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <32F446B6.598B.cygnus.gnu-win32@netcom.com> References: <199702020520 DOT QAA30142 AT mundook DOT cs DOT mu DOT OZ DOT AU> 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 Original-CC: gnu-win32 Original-Sender: owner-gnu-win32 AT cygnus DOT com 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 \ > bar > > is different from > > #define foo \ > 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 \ 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 | "I have always known that the pursuit > WWW: | of excellence is a lethal habit" > PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 3 | -- the last words of T. S. Garp. Life itself is lethal; don't let that stand in your way. -- - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".