On Tue, 2008-10-28 at 10:15 -0400, James Carlson wrote:
> Peter Memishian writes:
> >
> > > I think there's a bug in <sys/types.h> in that B_TRUE and B_FALSE
> > > disappear from the namespace if you request XOPEN_ or POSIX compliance
> > > with extensions via defines such as:
> > >
> > > -D_XOPEN_SOURCE=500 -D__EXTENSIONS__
> >
> > I agree this seems bogus. I've seen folks workaround it by #defining
> > B_TRUE to _B_TRUE and (e.g., in Makefiles).
>
> It seems bogus, but if I recall correctly, the standards conformance
> gurus say that we're not allowed to walk into the user's name space in
> this way: those symbols are defined by the standards, so they must not
> exist.
That appears to be true if __EXTENSIONS__ is not defined, but in this
case it is -- __EXTENSIONS__ is supposed to allow symbols not
specifically mentioned in the standard to appear.
> The real breakage here, I think, is that ancillary data is
> inaccessible from native (Solaris; not standards-compliant) sockets.
> That's *really* bogus.
Indeed. Back in 2005, I wrote (in section 6.2 of the PSARC opinion for
2005/683):
Unnecessarily divergent behavior between standards-compliant
and default variants of the commands we ship in Solaris is a
recurring source of irritation, confusion, and dissatisfac-
tion. While each individual instance of divergence is
minor, the cumulative impact is akin to that of a thousand
paper cuts.
This is really the same problem in a different context (libraries rather
than commands).
- Bill
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
