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

30 Jan 1997 23:57:03 -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] (Jim Balter)
Original-Cc: [email-masked]
In-Reply-To: <[email-masked]> from "Jim Balter" at Jan 27, 97 09:00:27 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Length: 2237      
Original-Sender: [email-masked]

> 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.

POSIX is a flawed standard and always has been.  It is fundamentally
incompatible with the already-established ANSI standard for C programming while
offering no substantial gains in its incompatibility.  For this reason, the
POSIX standard should and must be ignored where such incompatibilities arise as
it is the only sane response to such an assenine flaw.

> 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.

If you are stating that the GNU project will not accept submissions of code
fixes which bring GNU programs into ANSI-compliance, then either those in
charge of the GNU project are morons (for requiring their code to be
nonstandard) or you are an idiot (for speaking incorrectly on behalf of others
whose positions you do not know).  I do not for certain know which is more
likely, but either option is unacceptable.

If you are not stating this, then I am not sure what you are attempting to say.

> 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.

...nor is it prohibited by the ANSI specification.

-alex
-------------------------------------------------------------------------------
     Alex Stewart - [email-masked] - Richelieu @ Diversity University MOO
                         http://www.crl.com/~riche
           "For the world is hollow, and I have touched the sky."
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".