From: jqb AT rain DOT org (Jim Balter) Subject: Re: ASCII and BINARY files. Why? 27 Jan 1997 22:59:43 -0800 Approved: cygnus DOT gnu-win32 AT cygnus DOT com Distribution: cygnus Message-ID: <199701280500.VAA04079.cygnus.gnu-win32@coyote.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Original-To: Paul AT chocolat DOT foobar DOT co DOT uk (Paul Shirley) Original-Cc: smueller AT microsoft DOT com, gnu-win32 AT cygnus DOT com In-Reply-To: from "Paul Shirley" at Jan 27, 97 06:40:57 pm X-Mailer: ELM [version 2.4 PL24] Original-Sender: owner-gnu-win32 AT cygnus DOT com Paul Shirley wrote: > > In message 04-IMC.microsoft.com>, Stephan Mueller writes > >I agree that the 't' flag is really handy to have around. > > > >IMO, the only way to truly solve this problem once and for all is to > >gradually incorporate text/binary mode awareness into the official GNU > >sources. That means that all fopens that really mean to open in binary > >should have the 'b' added, and all code that follows fopens that really > >mean text mode should be examined and changed if they assume things like > >'the size of the file equals the number of charcters in a read of the > >whole file'. The code isn't 'bad' the way it is, it's just > >Unix-centric, and not entirely ANSI conformant. Of course it's Unix-centric; it's GNU code, and GNU project is a Unix emulation. Of course it isn't entirely ANSI conformant; *no* complex or professional-quality code is entirely ANSI conformant (and I say this as a former member of X3J11, the ANSI C standards committee). GNU code isn't even entirely POSIX compliant, and POSIX is what's relevant here. > >It will be more useful > >and more portable if these things are fixed, and I'm sure in time they > >will be. Why be sure of something that's probably false? The GNU project has limited goals, and they explicitly do not include 16-bit systems, systems that don't use / in filenames, systems that have separate text and binary modes, etc. Notably, in POSIX systems, reading as many bytes from a file as stat says it contains is perfectly appropriate behavior, and GNU code won't be "dumbed" down for the sake of non-POSIX systems. > AFAIK the djgpp port already handles 't' and O_TEXT modes. I had assumed > that this came from the gnu sources ( I assumed that because who else > would add an O_BIN flag when native DOS compilers all use O_BINARY ;) Well, if djgpp defined O_BIN, then obviously djgpp would. There is no 't' or O_TEXT or O_BIN or O_BINARY mode in GNU. And there is no 't' mode defined in ANSI, nor is there any open() call in ANSI to even take an O_BINARY or O_TEXT flag. > If not, borrowing from the djgpp source should be fairly > straightforward. ANSI does not provide for defaulting to binary when there are both text and binary file modes, so borrowing this would not make cygwin consistent with ANSI or POSIX. - For help on using this list, send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".