1: Conformance of the GNU libc with various standards 2: ================================================== 3: 4: The GNU libc is designed to be conformant with existing standard as 5: far as possible. To ensure this I've run various tests. The results 6: are presented here. 7: 8: 9: Open Group's hdrchk 10: =================== 11: 12: The hdrchk test suite is available from the Open Group at 13: 14: ftp://ftp.rdg.opengroup.org/pub/unsupported/stdtools/hdrchk/ 15: 16: I've last run the suite on 2004-04-17 on a Linux/x86 system running 17: a Fedora Core 2 test 2 + updates with the following results [*]: 18: 19: FIPS No reported problems 20: 21: POSIX90 No reported problems 22: 23: XPG3 Prototypes are now in the correct header file 24: 25: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 26: *** Starting unistd.h 27: Missing: extern char * cuserid(); 28: Missing: extern int rename(); 29: *** Completed unistd.h 30: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 31: 32: XPG4 Prototype is now in the correct header file 33: and the _POSIX2_C_VERSION symbol has been removed 34: 35: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 36: *** Starting unistd.h 37: Missing: extern char * cuserid(); 38: Missing: #define _POSIX2_C_VERSION (-1L) 39: *** Completed unistd.h 40: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 41: 42: POSIX96 Prototype moved 43: (using "base realtime threads" subsets) 44: 45: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 46: *** Starting unistd.h 47: Missing: extern int pthread_atfork(); 48: *** Completed unistd.h 49: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 50: 51: UNIX98 Prototypes moved and _POSIX2_C_VERSION removed 52: (using "base realtime threads mse lfs" subset) 53: 54: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 55: *** Starting unistd.h 56: Missing: extern char * cuserid(); 57: Missing: #define _POSIX2_C_VERSION (-1L) 58: Missing: extern int pthread_atfork(); 59: *** Completed unistd.h 60: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 61: 62: 63: That means all the reported issues are due to the headers having been 64: cleaned up for recent POSIX/Unix specification versions. Duplicated 65: prototypes have been removed and obsolete symbols have been removed. 66: Which means that as far as the tests performed by the script go, the 67: headers files comply to the current POSIX/Unix specification. 68: 69: 70: [*] Since the scripts are not clever enough for the way gcc handles 71: include files (namely, putting some of them in gcc-local directory) I 72: copied over the iso646.h, float.h, and stddef.h headers and ignored the 73: problems resulting from the split limits.h file). 74: 75: 76: Technical C standards conformance issues in glibc 77: ================================================= 78: 79: If you compile programs against glibc with __STRICT_ANSI__ defined 80: (as, for example, by gcc -ansi, gcc -std=c89, gcc -std=iso1990:199409 81: or gcc -std=c99), and use only the headers specified by the version of 82: the C standard chosen, glibc will attempt to conform to that version 83: of the C standard (as indicated by __STDC_VERSION__): 84: 85: GCC options Standard version 86: -ansi ISO/IEC 9899:1990 87: -std=c89 ISO/IEC 9899:1990 88: -std=iso9899:199409 ISO/IEC 9899:1990 as amended by Amd.1:1995 89: -std=c99 ISO/IEC 9899:1999 90: 91: (Note that -std=c99 is not available in GCC 2.95.2, and that no 92: version of GCC presently existing implements the full C99 standard.) 93: 94: You may then define additional feature test macros to enable the 95: features from other standards, and use the headers defined in those 96: standards (for example, defining _POSIX_C_SOURCE to be 199506L to 97: enable features from ISO/IEC 9945-1:1996). 98: 99: There are some technical ways in which glibc is known not to conform 100: to the supported versions of the C standard, as detailed below. Some 101: of these relate to defects in the standard that are expected to be 102: fixed, or to compiler limitations. 103: 104: 105: Defects in the C99 standard 106: =========================== 107: 108: Some defects in C99 were corrected in Technical Corrigendum 1 to that 109: standard. glibc follows the corrected specification. 110: 111: 112: Implementation of library functions 113: =================================== 114: 115: The implementation of some library functions does not fully follow the 116: standard specification: 117: 118: C99 added additional forms of floating point constants (hexadecimal 119: constants, NaNs and infinities) to be recognised by strtod() and 120: scanf(). The effect is to change the behavior of some strictly 121: conforming C90 programs; glibc implements the C99 versions only 122: irrespective of the standard version selected. 123: 124: C99 added %a as another scanf format specifier for floating point 125: values. This conflicts with the glibc extension where %as, %a[ and 126: %aS mean to allocate the string for the data read. A strictly 127: conforming C99 program using %as, %a[ or %aS in a scanf format string 128: will misbehave under glibc. 129: 130: 131: Compiler limitations 132: ==================== 133: 134: The macros __STDC_IEC_559__, __STDC_IEC_559_COMPLEX__ and 135: __STDC_ISO_10646__ are properly supposed to be defined by the 136: compiler, and to be constant throughout the translation unit (before 137: and after any library headers are included). However, they mainly 138: relate to library features, and the necessary magic has yet to be 139: implemented for GCC to predefine them to the correct values for the 140: library in use, so glibc defines them in <features.h>. Programs that 141: test them before including any standard headers may misbehave. 142: 143: GCC doesn't support the optional imaginary types. Nor does it 144: understand the keyword _Complex before GCC 3.0. This has the 145: corresponding impact on the relevant headers. 146: 147: glibc's use of extern inline conflicts with C99: in C99, extern inline 148: means that an external definition is generated as well as possibly an 149: inline definition, but in GCC it means that no external definition is 150: generated. When GCC's C99 mode implements C99 inline semantics, this 151: will break the uses of extern inline in glibc's headers. (Actually, 152: glibc uses `extern __inline', which is beyond the scope of the 153: standard, but it would clearly be very confusing for `__inline' and 154: plain `inline' to have different meanings in C99 mode.) 155: 156: glibc's <tgmath.h> implementation is arcane but thought to work 157: correctly; a clean and comprehensible version requires compiler 158: builtins. 159: 160: For most of the headers required of freestanding implementations, 161: glibc relies on GCC to provide correct versions. (At present, glibc 162: provides <stdint.h>, and GCC doesn't.) 163: 164: Implementing MATH_ERRNO, MATH_ERREXCEPT and math_errhandling in 165: <math.h> needs compiler support: see 166: 167: http://sources.redhat.com/ml/libc-hacker/2000-06/msg00008.html 168: http://sources.redhat.com/ml/libc-hacker/2000-06/msg00014.html 169: http://sources.redhat.com/ml/libc-hacker/2000-06/msg00015.html 170: 171: 172: Issues with headers 173: =================== 174: 175: None known.