This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove _BSD_SOURCE and _SVID_SOURCE
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 9 Dec 2013 17:53:12 +0000
- Subject: Re: Remove _BSD_SOURCE and _SVID_SOURCE
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1312052315530 dot 16480 at digraph dot polyomino dot org dot uk> <20131206023345 dot GX24286 at brightrain dot aerifal dot cx> <Pine dot LNX dot 4 dot 64 dot 1312082349280 dot 1824 at digraph dot polyomino dot org dot uk> <20131209041107 dot GN24286 at brightrain dot aerifal dot cx>
On Sun, 8 Dec 2013, Rich Felker wrote:
> 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
That sounds like a case for a feature test macro "enable extensions, but
not GNU deviations from POSIX semantics" (or something to disable such
deviations when using _GNU_SOURCE).
> 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.
I think "breakage" could only be considered to cover specifically cases
where a symbol has semantics with _GNU_SOURCE differing from its semantics
in POSIX - not new symbols, which could always break something using the
symbol internally in a different way. (Any specific concern about whether
symbol X should be in header Y as part of the default API or the
_GNU_SOURCE API is the sort of thing I noted should be raised in a
separate thread.)
> > "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.
The only such options enabled by -std=c99 are -fexcess-precision=standard
(only affects a few architectures, mainly 32-bit x86) and -ffp-contract=on
(synonymous with -ffp-contract=off; 4.9 and later, before then the default
was still -ffp-contract=fast even with -std=c99). The default options
include -fmath-errno -fno-unsafe-math-optimizations -fno-associative-math
-fno-reciprocal-math -fno-finite-math-only -fsigned-zeros -ftrapping-math
-fno-cx-limited-range and those are not effected by -std=c99 / -std=gnu99.
--
Joseph S. Myers
joseph@codesourcery.com