Glenn,
No! <sys/feature_tests.h> and related headers set things up
correctly for standards conformance only when macros requesting
standards conformance are set to known values. The headers and Solaris
developers know about the common parts of the standards and rely on the
macros to accurately reflect the commonality. If _POSIX_C_SOURCE is
defined to a value unknown to the headers, there is a good chance the
the overlaps between the XPG/SUS specs and the POSIX specs will get
confused and lead to nonstandard behavior.
I'm still having trouble with the concept of an application
asking for an unknown set of interfaces to stop working at some random
point in the future. A later revision of the standard could change the
size of various *_t data types, add or remove arguments to functions,
change the default behavior of various functions, etc. Any of these
could make the application fall over when recompiled with no indication
that there was a problem. Why would you prefer this to asking for
SUSv3 + extensions (which at least gives you known behavior for
everything specified by SUSv3 for the foreseeable future)?
Don
>Date: Wed, 03 Jan 2007 14:33:10 -0500
>From: Glenn Fowler <gsf at research.att.com>
>Subject: Re: _ISOC99_SOURCE
>To: don.cragun at sun.com, gsf at research.att.com
>Cc: Chris.Quenelle at sun.com, ksh93-integration-discuss at opensolaris.org,
lee.damico at sun.com
>MIME-version: 1.0
>Content-transfer-encoding: 7BIT
>X-PMX-Version: 5.2.0.264296
>
>
>On Wed, 3 Jan 2007 11:30:45 -0800 (PST) Don Cragun wrote:
>> Hi Glenn,
>> The best we can suggest at this point is to use:
>> #define _POSIX_C_SOURCE=200112L
>> #define __EXTENSIONS__
>> which will give you the interfaces specified by SUSv3/POSIX.1-2001 with
>> compatible extensions.
>
>thanks
>would something like
> #define _POSIX_C_SOURCE=210001L
>work?
>
