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

31 Jan 1997 00:49:15 -0800
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.01Gold (WinNT; I)
Original-To: [email-masked]
Original-Sender: [email-masked]

Alex Stewart wrote:
> 
> > 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.

Be careful of who you call asinine.  POSIX *conforms* to ANSI C.
Any program that *strictly conforms* to ANSI C is acceptable to POSIX,
and all conforming POSIX programs *conform* (but not strictly) to
ANSI C.  As the ANSI C standard states:
	A conforming implementation may have extensions (including
	additional library functions), provided they do not alter
	the behavior of an any strictly conforming program.

	(footnote) Strictly conforming programs are intended to be
	maximally portable among conforming implementations.
	Conforming programs may depend upon nonportable features
	of a conforming implementation.

Of course, since POSIX specifies an *operating system*, it has
many such extensions and features that aren't portable to other,
non-POSIX, ANSI C systems.  The idea that, say, access, alarm, chdir,
chmod, chown, close, closedir, creat, dup, dup2, execl, fcntl, fdopen,
fork, fstat, getcwd, getgid, open, read, write,
to name just a few, offer "no substantial gains" seems, well, asinine.

POSIX is carefully specified such that conforming POSIX implementations
are conforming ANSI C implementations.  I was on the ANSI C committee
when we changes at the request of the POSIX committee to assure that
this would be so.

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

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

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

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.

--
<J Q B>
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".