Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.std.c
Subject: Re: __STDC__ and POSIX
Message-ID: <885@auspex.UUCP>
Date: 20 Jan 89 22:37:57 GMT
References: <9391@smoke.BRL.MIL> <8731@megaron.arizona.edu> <9405@smoke.BRL.MIL> <860@auspex.UUCP> <866@auspex.UUCP> <9436@smoke.BRL.MIL>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 68


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

I agree.  If any excessively-legalistic type objects, they should be
ignored (unless they repeatedly object, in which case they should be
shot).  The goal of the standards is to help people do their jobs; given
that deciding whether the "implementation" or "the application" is
defining _POSIX_SOURCE is a matter of no practical importance
(except, perhaps, if you have incurably stupid people who won't read the
documentation and run provide the "-pedantic" or whatever flag to their
C compiler when compiling ANSI C/non-POSIX applications), I don't see
that your suggestion violates the spirit of either standard.

(The same logic applies to "-D" on the command line; the user
consciously decided to change the namespace in which they compiled their
application, presumably knowing precisely what the effect would be.  I
realize that the current state of liability law in the US seems, at
times, to tend towards the notion that no bad consequences of deciding
to do something aren't the fault of the person who decided to do it, but
I hope we can avoid thinking in those terms; the disclaimer you
suggested for the "-D" case sounds a bit like the disclaimer from the
apocryphal story of the steplatter planted in frozen manure that slipped
when the manure melted - the ladder's manufacturer was allegedly bullied
into applying a "don't stick the bottom of this ladder into frozen
manure, idiot" disclaimer to the product thanks to some stupid liability
suit....)

A similar approach could be taken for other extensions; perhaps there'd
be an option in S5R4, say, for the latest issue of the SVID (enabling,
for example, the definition of error numbers not found in POSIX), and
probably one for "open the floodgates wide", which includes stuff not
(or not yet) in the SVID.

All those versions would define __STDC__ as 1 (or 2 or later, in future
versions, presumably).  The "traditional" mode would probably turn
everything on; I agree that it would be prefereable that it not define
__STDC__ at all (although Peter da Silva's workaround isn't too bad - it
lets you use "#if __STDC__" at the expense of adding a few extra lines
of code, which you could presumably put in your application's
"unwedge_stdc.h" or something such as that).  Given that there would be
other "feature test macros" for the other options, (__STDC__ == 0)
wouldn't be needed as a way of *enabling* namespace-polluting features
(which is, I think, one of the functions for which AT&T wanted to use
it).

I don't see that (__STDC__ == 0) is all that useful for e.g. enabling
code that uses prototypes on applications that can use prototypes when
compiled in a compiler that has them but isn't ANS-conformant:

	1) if you're rewhacking your code to use prototypes, you might
	   want to rewhack it to conform to the ANS;

	2) you can define your own feature test macros for this, and
	   have some little prologue that defines _HAS_PROTOTYPES if
	   __STDC__ is defined and (greater than or) equal to 1, and
	   forcibly pre-define them on the implementations that have
	   prototypes but aren't ANS-conformant;

	3) if all else fails, you may be able to forcibly define
	   __STDC__ as 0 on the command line.