from a single vendor's perspective I see your point
but
for portability our code tends to iffe (configure) apis we know to be in flux
in general this gives us less headaches than asking for specific standard
freeze points
otherwise we would have to maintain a sys/features parallel universe just
for our code
e.g., we could target for XOPEN 2001
but what about systems that don't implement it?
what about vendors that trickle down the standard apis as they burn them in?
there are even vendors that claim conformance when they're < 100% conformant
and then there's the vendors that provide the apis, but they errno with ENOSYS
its much easier for us to add a few iffe tests than to track the matrix of
standards X vendors X releases
of course this model means that some standard changes, like sizeof(*_t),
might require a rebuild of our source -- still an easier price to pay than
#if posix < 1990
#elif posix == 2001
#if and this vendor knows what 2001 means
#else
workaround for vendor foo standard bar
#endif
#elif whatever
#endif
even if we did target for specific standards we'd still have to iffe
otherwise we'd loose customers on systems that claim conformance but
aren't conformant, and the non-conformance prevents our code from
building/running
--Glenn
On Wed, 3 Jan 2007 14:21:05 -0800 (PST) Don Cragun wrote:
> 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?
> >
