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

27 Jan 1997 22:59:43 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Original-To: [email-masked] (Paul Shirley)
Original-Cc: [email-masked], [email-masked]
In-Reply-To: <[email-masked]> from "Paul Shirley" at Jan 27, 97 06:40:57 pm
X-Mailer: ELM [version 2.4 PL24]
Original-Sender: [email-masked]

Paul Shirley wrote:
> 
> In message <c=US%a=_%p=msft%l=RED-67-MSG-970127183114Z-12470@INET-
> 04-IMC.microsoft.com>, Stephan Mueller <[email-masked]> 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
"[email-masked]" with one line of text: "help".