On Sun, 25 Sep 2011, Joern Rennecke wrote: > ! <p>"Library Issue" means that support may or may not be available depending > ! on the C library used; for example, the GNU C library supports all C99 > ! features, provided _ISOC99_SOURCE and/or _GNU_SOURCE is defined in the > ! source code or with a -D preprocessor flag.
Referring to these feature test macros is not a good idea, the normal way for them to be defined is internally by libc in response to __STDC_VERSION__ defined by the compiler. (There are various miscellaneous conformance issues in glibc as well. Apart from what's mentioned in libc's CONFORMANCE file: * Macros that should be usable in #if defined as enums. * <math.h> and <complex.h> do not declare long double functions when same representation as double (fixed in EGLIBC by a patch of Jakub's that was ignored for FSF glibc). * Mathematical function error handling generally a mess: GLIBC bugs 3866 3868 5680 6759 6776-6788 6792-6799 6801-6810 6814 (this list of bug numbers may be out of date). * Mathematical functions broken in non-default rounding modes: GLIBC bugs 3976 6869. * Headers redirect functions to standard versions in some cases where C requires this to work without explicitly including headers (might be fixable with pragma redefine_extname in implicitly included header). * wmemcmp/wcscmp handling of some wchar_t values (see recent libc-alpha discussion; clearly a C94 and C1X conformance bug, less clearly a C99 bug). * Power Architecture malloc alignment <http://sourceware.org/ml/libc-alpha/2007-11/msg00062.html> (see more recent discussion of this patch in the x32 context). * Fixes to fenv.h fallback functions were rejected 2011-01-08. * ARM, MIPS wrongly save/restore fp state in setjmp/longjmp. I'd welcome details of any other issues people think are C standards conformance bugs in glibc. (I also have some notes of possible issues in the soft-fp code and architecture-specific issues in some mathematical functions.)) -- Joseph S. Myers jos...@codesourcery.com
