diff options
Diffstat (limited to 'REORG.TODO/CONFORMANCE')
-rw-r--r-- | REORG.TODO/CONFORMANCE | 168 |
1 files changed, 168 insertions, 0 deletions
diff --git a/REORG.TODO/CONFORMANCE b/REORG.TODO/CONFORMANCE new file mode 100644 index 0000000000..b23318ee9d --- /dev/null +++ b/REORG.TODO/CONFORMANCE @@ -0,0 +1,168 @@ +Conformance of the GNU libc with various standards +================================================== + +The GNU libc is designed to be conformant with existing standard as +far as possible. To ensure this I've run various tests. The results +are presented here. + + +Open Group's hdrchk +=================== + +The hdrchk test suite is available from the Open Group at + + ftp://ftp.rdg.opengroup.org/pub/unsupported/stdtools/hdrchk/ + +I've last run the suite on 2004-04-17 on a Linux/x86 system running +a Fedora Core 2 test 2 + updates with the following results [*]: + + FIPS No reported problems + + POSIX90 No reported problems + + XPG3 Prototypes are now in the correct header file + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +*** Starting unistd.h +Missing: extern char * cuserid(); +Missing: extern int rename(); +*** Completed unistd.h +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + XPG4 Prototype is now in the correct header file + and the _POSIX2_C_VERSION symbol has been removed + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +*** Starting unistd.h +Missing: extern char * cuserid(); +Missing: #define _POSIX2_C_VERSION (-1L) +*** Completed unistd.h +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + POSIX96 Prototype moved + (using "base realtime threads" subsets) + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +*** Starting unistd.h +Missing: extern int pthread_atfork(); +*** Completed unistd.h +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + UNIX98 Prototypes moved and _POSIX2_C_VERSION removed + (using "base realtime threads mse lfs" subset) + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +*** Starting unistd.h +Missing: extern char * cuserid(); +Missing: #define _POSIX2_C_VERSION (-1L) +Missing: extern int pthread_atfork(); +*** Completed unistd.h +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +That means all the reported issues are due to the headers having been +cleaned up for recent POSIX/Unix specification versions. Duplicated +prototypes have been removed and obsolete symbols have been removed. +Which means that as far as the tests performed by the script go, the +headers files comply to the current POSIX/Unix specification. + + +[*] Since the scripts are not clever enough for the way gcc handles +include files (namely, putting some of them in gcc-local directory) I +copied over the iso646.h, float.h, and stddef.h headers and ignored the +problems resulting from the split limits.h file). + + +Technical C standards conformance issues in glibc +================================================= + +If you compile programs against glibc with __STRICT_ANSI__ defined +(as, for example, by gcc -ansi, gcc -std=c89, gcc -std=iso1990:199409 +or gcc -std=c99), and use only the headers specified by the version of +the C standard chosen, glibc will attempt to conform to that version +of the C standard (as indicated by __STDC_VERSION__): + +GCC options Standard version +-ansi ISO/IEC 9899:1990 +-std=c89 ISO/IEC 9899:1990 +-std=iso9899:199409 ISO/IEC 9899:1990 as amended by Amd.1:1995 +-std=c99 ISO/IEC 9899:1999 + +(Note that -std=c99 is not available in GCC 2.95.2, and that no +version of GCC presently existing implements the full C99 standard.) + +You may then define additional feature test macros to enable the +features from other standards, and use the headers defined in those +standards (for example, defining _POSIX_C_SOURCE to be 199506L to +enable features from ISO/IEC 9945-1:1996). + +There are some technical ways in which glibc is known not to conform +to the supported versions of the C standard, as detailed below. Some +of these relate to defects in the standard that are expected to be +fixed, or to compiler limitations. + + +Defects in the C99 standard +=========================== + +Some defects in C99 were corrected in Technical Corrigendum 1 to that +standard. glibc follows the corrected specification. + + +Implementation of library functions +=================================== + +The implementation of some library functions does not fully follow the +standard specification: + +C99 added additional forms of floating point constants (hexadecimal +constants, NaNs and infinities) to be recognised by strtod() and +scanf(). The effect is to change the behavior of some strictly +conforming C90 programs; glibc implements the C99 versions only +irrespective of the standard version selected. + +C99 added %a as another scanf format specifier for floating point +values. This conflicts with the glibc extension where %as, %a[ and +%aS mean to allocate the string for the data read. A strictly +conforming C99 program using %as, %a[ or %aS in a scanf format string +will misbehave under glibc if it does not include <stdio.h> and +instead declares scanf itself; if it gets the declaration of scanf +from <stdio.h>, it will use a C99-conforming version. + + +Compiler limitations +==================== + +The macros __STDC_IEC_559__, __STDC_IEC_559_COMPLEX__ and +__STDC_ISO_10646__ are properly supposed to be constant throughout the +translation unit (before and after any library headers are included). +However, they mainly relate to library features, and GCC only knows to +preinclude <stdc-predef.h> to get their definitions in version 4.8 and +later. Programs that test them before including any standard headers +may misbehave with older compilers. + +GCC doesn't support the optional imaginary types. Nor does it +understand the keyword _Complex before GCC 3.0. This has the +corresponding impact on the relevant headers. + +glibc's <tgmath.h> implementation is arcane but thought to work +correctly; a clean and comprehensible version requires compiler +builtins. + +For most of the headers required of freestanding implementations, +glibc relies on GCC to provide correct versions. (At present, glibc +provides <stdint.h>, and GCC doesn't before version 4.5.) + +The definition of math_errhandling conforms so long as no translation +unit using math_errhandling is compiled with -fno-math-errno, +-fno-trapping-math or options such as -ffast-math that imply these +options. math_errhandling is only conditionally defined depending on +__FAST_MATH__; the compiler does not provide the information needed +for more exact definitions based on settings of -fno-math-errno and +-fno-trapping-math, possibly for only some source files in a program. + + +Issues with headers +=================== + +None known. |