🚀 go-pugleaf

In article <12040005@hpfcdc.HP.COM> donn@hpfcdc.HP.COM (Donn Terry) writes:
>I want to respond to some of the comments made about _POSIX_SOURCE ...

Thanks for the discussion, Donn.  I have no major objection to anything
you said, and am heartened to hear that "posix_std_cc ansi.c", where
ansi.c is a strictly-conformant ANSI C program, will allow my ansi.c to
"#include <stdio.h>" without fdopen() getting declared as a side-effect.

I'm still not clear on just how it's going to be arranged that
	cc ansi.c
	cc old_unix.c
	cc posix.c
(where old_unix.c is existing UNIX code and posix.c avails itself of
1003.1 features) can all use the same "cc".  AT&T's __STDC__==0 mode
is apparently supposed to have something to do with this, but I don't
see how, without providing what is essentially a separate way to invoke
the compiler for at least one of the three cases.  From e-mail I
received from Dave Prosser, I have the impression that AT&T intends
for "cc" to by default be non-conforming to the ANSI C standard, and
for applications that want ANSI C conformance to have to do something
extra (perhaps add a flag to CFLAGS in their Makefiles?).  He did say
that __STDC__ is always defined as either 0 or 1 in their implementation,
with the 0 case deviating from ANSI C conformance only in adding the
"asm" keyword to the language and in adding extra (not necessarily
limited to POSIX) identifiers to the standard headers for purposes of
compatibility with previous UNIX compilation environments.  The claim
was made that that's what their customers want, but I'm an AT&T
customer too and I don't recall being polled for my opinion on this..