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

2 Feb 1997 20:39:20 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Original-To: [email-masked] (Jim Balter)
Original-Cc: [email-masked]
In-Reply-To: <[email-masked]> from "Jim Balter" at Jan 30, 97 07:46:28 pm
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4189      
Original-Sender: [email-masked]

First off, let me say that when I posted my earlier message I wasn't in the
best of moods (having been over and over and over this whole discussion in many
different arenas already, and never seeing any end to it), and probably used
some words I shouldn't have.  My points, however, remain.
  
> > 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.
> 
> Be careful of who you call asinine.  POSIX *conforms* to ANSI C.

ANSI C requires that files are opened in text mode by default.  POSIX requires
that there is no distinction between text and binary files.  These two
standards can coexist only on underlying systems where there is no distinction
between file types (such as POSIX OSes).  Win32 is not a POSIX OS environment
in that it does distinguish between text and binary file types, and therefore
ANSI C requires that files be opened with newline conversions by default,
however the POSIX C standard requires that they not be.  This is a fundamental
incompatibility which renders POSIX inherently _incompatible_ with ANSI C
(please note here that we are discussing the POSIX API standard, not the larger
POSIX OS standards.  Such issues in an OS specification would easily be
dismissed by simply saying "well, Win32 isn't a POSIX OS", however the POSIX
API specification should be applicable in an ANSI C, non-POSIX OS environment
(as is exactly what people are attempting with GNU-Win32), and the fact that it
cannot be is still a flaw)

> Perhaps someone around here is an idiot and a moron, but it isn't
> me or those in charge of the GNU project.  Since GNU programs require
> many POSIX extensions to ANSI C, such as, say, "stat", it is pointless
> to try to make GNU programs *strictly* ANSI conforming.  But programs
> that conform to POSIX already conform (but not strictly) to ANSI C.

They do not conform to ANSI C if they (for example) fopen a file without a "b"
flag and expect to read/write binary data from it without problems.  Many GNU
utilities do this and are therefore incompatible with the ANSI C standard
(strictly or otherwise).  There is no reason for this as it is possible to
design application code in such a way that it will function correctly under
both systems, and therefore any code which does not is flawed and requires a
bug fix.  If the GNU project will not accept such bug fixes (thus requiring
their software to be incompatible with ANSI standards) for no reason other than
"we don't want it that way", then I reiterate my statement that they are
morons.

> I really don't think that understanding this distinction makes one
> an idiot or a moron.  I suggest you think twice or more before throwing
> those words around.

Understanding the distinction is not the issue.  Requiring incompatibility for
no reason is the issue, and it is still a valid one.  If you don't like my
choice of words, fair enough, but it doesn't change the actual issues involved.

> While strictly conforming ANSI C programs can use fopen(file, "rt"),
> they cannot use open, O_BIN, O_BINARY, or O_TEXT.  And if they
> do use "rt", they cannot depend upon its effects and still be strictly
> conforming.  Since the meaning of none of these is defined by either
> ANSI C nor POSIX, their use is not portable.

Under an ANSI-compatible system, "t" is unnecessary as all files are opened in
text mode by default, therefore "depending on its effect" (its effect being
that it doesn't need one) is a non-issue.  One would only need to depend on its
effect within an environment which itself did not conform to these standards
anyway, and therefore the point becomes moot.

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