This is the mail archive of the 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]


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

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