Path: utzoo!attcan!uunet!husc6!mailrus!purdue!decwrl!pyramid!hplabs!hpfcdc!donn
From: donn@hpfcdc.HP.COM (Donn Terry)
Newsgroups: comp.std.c
Subject: Re: Re: __STDC__, _POSIX_SOURCE, etc.
Message-ID: <12040008@hpfcdc.HP.COM>
Date: 23 Jan 89 05:36:13 GMT
References: <9458@smoke.BRL.MIL>
Organization: HP Ft. Collins, Co.
Lines: 51

To fill in a detail that came up in the discussions of now _POSIX_SOURCE
was to work.

It became pretty obvious that there were *very* few non-trivial programs
that were 100% POSIX conformant "by accident".  Thus to be POSIX conforming
the program would have to change at least slightly.  At that time, adding
_POSIX_SOURCE to the source code is not a big concern.  (Not that we
wanted things to change, but a lot of little things had to; UNIX had
just collected too much cruft over time.)  For the programs that are
already 100% POSIX conformant, congratulations to the authors!  (for
clarivoiance :-) ).  (I think there's a better chance for pure ANSI
programs, but I have a hunch that there's not a lot of them either.  I
do believe that for either ANSI C or POSIX the changes to conform are
either trivial or nearly impossible (not much middle ground).  In the
latter case, wait for 1003.4, or whatever.)

We also realized that many vendors would want to provide a backwards
compatible environment (either because they hadn't gotten an ANSI C
compiler on line, or that they had both).  Thus _POSIX_SOURCE had the
special meaning for common usage, which gave the same set of external
symbols (ANSI+POSIX) in both possible C environments.

For "unreconstructed" source (just about all there is today) the user
uses the "old" compiler, however the vendor specifies it (and it
is probable that that will be "cc" with no options initially).  This
is a "no changes and it still works" environment.  As the programs 
are inspected for ANSI/POSIX conformance, switches are set on the
compile line and in the source (_POSIX_SOURCE) to address the
exact environment needed.  Of course if there is a huge collection
of source that needs it and not other changes, it can be put into
CFLAGS for the make.  I suspect that the default will change to be
ANSI in a few years, and a few years after that the issue will go
away.  

I am *very* pleased at the 1003.2  -v ansi / -v common idea.  By
standardizing this, a big set of portability problems are cured
because it brings back a higher degree of portability in makefiles,
almost to where we started from.  (Now if that standard would only
hurry up and get ratified.)

As a software writer, I'm not sure I'd want to have _POSIX_SOURCE 
defined by the compiler for me (not counting my own -D, of course).
Before converting to POSIX, I'd want my same old environment.  
After, I'd prefer to be in control.

Donn Terry
Chair 1003.1

I speake only for myself; neither my employer nor IEEE necessarily
share the same opinions.   (You ought to see the "official" long form
of this!)