diff options
author | Zack Weinberg <zackw@panix.com> | 2017-09-01 08:04:22 -0400 |
---|---|---|
committer | Zack Weinberg <zackw@panix.com> | 2017-09-01 08:04:22 -0400 |
commit | da162bf23403009af7a7406b9007a8141c4576ab (patch) | |
tree | dca8acd833ef53ce8fe8f48a8fbe699d3ce7e2eb /CONFORMANCE | |
parent | f4a6be2582b8dfe8adfa68da3dd8decf566b3983 (diff) | |
download | glibc-da162bf23403009af7a7406b9007a8141c4576ab.zip glibc-da162bf23403009af7a7406b9007a8141c4576ab.tar.gz glibc-da162bf23403009af7a7406b9007a8141c4576ab.tar.bz2 |
Remove obsolete notes at top level of source tree.
* BUGS, CONFORMANCE, NAMESPACE, WUR-REPORT: Deleted.
* README.pretty-printers, README.tunables: Move to manual/.
Diffstat (limited to 'CONFORMANCE')
-rw-r--r-- | CONFORMANCE | 168 |
1 files changed, 0 insertions, 168 deletions
diff --git a/CONFORMANCE b/CONFORMANCE deleted file mode 100644 index b23318e..0000000 --- a/CONFORMANCE +++ /dev/null @@ -1,168 +0,0 @@ -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. |