This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remove _BSD_SOURCE and _SVID_SOURCE


On Sun, Dec 08, 2013 at 11:53:13PM +0000, Joseph S. Myers wrote:
> On Thu, 5 Dec 2013, Rich Felker wrote:
> 
> > On Thu, Dec 05, 2013 at 11:17:59PM +0000, Joseph S. Myers wrote:
> > > In more detail:
> > > 
> > > The status quo is that the features enabled by _BSD_SOURCE or
> > > _SVID_SOURCE are enabled (a) if the applicable one of those macros is
> > > defined by the user (a case that will no longer be supported), (b) by
> > > default, if the user didn't use a compiler option such as -ansi or
> > > -std=c99 that defines __STRICT_ANSI__ and didn't define
> > > _ISOC99_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE or _XOPEN_SOURCE (or
> > > _BSD_SOURCE or _SVID_SOURCE), (c) if _GNU_SOURCE is defined.  There's
> > > the oddity of (b) not checking _ISOC11_SOURCE, but it's not the
> > > function of this patch to change anything in that regard.
> > 
> > I'm not 100% against this change, but how do you propose getting the
> > current default profile of what's exposed in the header along with
> > correct C semantics at the compiler level? -std=c99 and -std=c11,
> > which are needed to get the compiler to behave right (gnu99 has lots
> > of problems), define __STRICT_ANSI__ which inhibits all the default
> > features. -U__STRICT_ANSI__ might work but this seems hackish...
> 
> There is no feature to get the default API with -std=c99 is used; I didn't 
> see a need for a feature-test macros for something pretty poorly defined 
> (I'm pretty sure it includes plenty of things that are not actually BSD or 
> SVID), having an expectation that users selecting strict conformance modes 
> in the compiler will want to use feature test macros such as 
> _POSIX_C_SOURCE for the library features they need.  (It's already the 
> case without this patch that details such as __USE_POSIX_IMPLICITLY and 
> __FAVOR_BSD cannot be replicated by feature test macros.)

My frustration is that glibc makes it really hard to get an
environment that conforms to the standards in places where the
standards have something to say but that also provides additional
features most people want. For instance you lose MAP_ANONYMOUS if you
request _POSIX_C_SOURCE or _XOPEN_SOURCE, but if you use _GNU_SOURCE
to get it back, you also get broken strerror_r, broken basename, and
lots of unwanted namespace pollution (like stdlib.h -> sys/types.h ->
sys/sysmacros.h leading to macros named major() and minor() being
defined.

Perhaps what I should really be doing is requesting a feature test
macro to get extensions without any breakage.

> "gnu99 has lots of problems" is not a helpful description of whatever 
> reasons people may have for using -std=c99 (and most of the differences 
> between them also have their own options for more fine-grained control).

The first thing that comes to mind is that it turns off all of the
IEEE floating point/Annex F conformance options of -std=c99 in favor
of giving a performance-optimized math profile. I can't remember right
off if there are other issues.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]