Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!hplabs!hpfcdc!donn
From: donn@hpfcdc.HP.COM (Donn Terry)
Newsgroups: comp.std.c
Subject: Re: Re: __STDC__ and POSIX
Message-ID: <12040007@hpfcdc.HP.COM>
Date: 20 Jan 89 05:45:00 GMT
References: <9436@smoke.BRL.MIL>
Organization: HP Ft. Collins, Co.
Lines: 103

>...
>I think the logical consequence of all this is that in a
>simultaneously ANSI C and IEEE 1003.1 conforming implementation,
>applications would have to be sure to defined _POSIX_SOURCE if
>they want to get at the POSIX-specific symbols in those headers
>specified by the C Standard.  This is obviously a nuisance, and
>consequently it is probable that there will be few attempts to
>provide simultaneously-conforming implementations and fewer
>attempts on the part of applications to use them.  This is a
>real lossage.

In fact, to my knowledge, an implementation that requires a #define
_POSIX_SOURCE is the preferred one as all the compiler organization has
to do is provide an ANSI compiler.  The headers are extended by the OS
group to include the POSIX symbols conditionally, and if the user wants
them, he asks.  The user decides what he wants in his source program.
Nice, clean, and simple.  It never breaks ANSI C.  It assures that
makefiles don't have to know the subtleties of which switches to set in
which modules.  It warns the reader of the program what symbol set he
should expect up front, rather than having to look at the makefile.
It makes sure the switch settings don't get separated from the program.

We did consider the possiblility of predefining the symbol in the 
compiler, but discarded it because of some of the other issues that
came up elsewhere in this discussion: if you predifine a symbol from
the outside, does that require turing off __STDC__?  (At the time it
appeared to.)  Or, how do you turn it off.  Or, as Bob Lenk observes,
how do you handle the combinatorics of N standards all of which need
switches.  (IEEE 1003.* is poised at going over into two digits;
each of those probably represents a standard or two or three.  GACK!)

>My hope is that in the UNIX world the following slightly
>cheating position will become widely adopted as a compromise
>solution of most benefit to the programmer who is also concerned
>with portability issues:

>	The new default compilation environment predefines
>	_POSIX_SOURCE "on behalf of the application", i.e. it is
>	NOT considered as being provided by the official
>	"implementation" but by the "program" being compiled.

It's intended to be provided by and in the program.  Weasel words
to do this aren't needed.

>	The shared standard headers key on _POSIX_SOURCE to enable
>	the POSIX extensions beyond the ANSI C specification.

That's easy and being done.

>	Except for the header extensions enabled by _POSIX_SOURCE,
>	the ANSI C Standard is obeyed.
>
>	__STDC__ is defined as 1.
>

No problem with that.

>As an acceptable but slightly less convenient alternative that can
>be coped with easily by POSIX applications adding -D_POSIX_SOURCE to
>CFLAGS in Makefiles:
> ...

What's wrong with putting it in the program?  That was the intent.
(As mentioned elsewhere, if the implementation doesn't conform to POSIX,
you've got bigger problems than a single flag can solve, anyway.  At
that point you use compilation flags from the command line to turn on/off
the bits and pieces you need, and if _POSIX_SOURCE needs to be turned
off, don't turn it on by:

	#ifndef NOT_POSIX
	#define _POSIX_SOURCE
	#endif

>The key to this is that, because the "program" is defining the
>identifier _POSIX_SOURCE, which is in the name space reserved for
>implementations, technically by the ANSI C Standard the realm of
>"undefined behavior" has been entered.  Basically, POSIX
>implementations would define the behavior in this case to be that
>outlined above.
>
>This solution does NOT work if it is the "implementation" that is
>considered to be defining _POSIX_SOURCE.

POSIX is best considered an implementation from the ANSI C point of
view.  Thus _POSIX_SOURCE is considered a symbol reserved to a
particular implementation (and thus outside ANSI C control).  How that
symbol is used by that implementation is up to the implementation.
Here we get into some subtleties of the meaning of the word "define".
In the sense of the English language, it means to associate a meaning
with it.  In the usual computer sense it means "add it to the symbol
table".  In this case, POSIX defines a meaning for that symbol (in
the English sense), and only when the user defines it (in the computer
sense) does it actually have an effect.  From the point of view of
ANSI C the symbol simply doesn't exist: either it isn't used, or 
if it is, you enter the realm of "undefined behavior" and ANSI can't
talk about it.  (But POSIX can, and the first thing it says is "it's
still just like ANSI but you got some more symbols from outside".)

Donn Terry
Chair, IEEE 1003.1

In this I represent only myself.  Neither my employer or IEEE necessarily
endorse any position presented here.