aboutsummaryrefslogtreecommitdiff
path: root/CONFORMANCE
diff options
context:
space:
mode:
authorZack Weinberg <zackw@panix.com>2017-09-01 08:04:22 -0400
committerZack Weinberg <zackw@panix.com>2017-09-01 08:04:22 -0400
commitda162bf23403009af7a7406b9007a8141c4576ab (patch)
treedca8acd833ef53ce8fe8f48a8fbe699d3ce7e2eb /CONFORMANCE
parentf4a6be2582b8dfe8adfa68da3dd8decf566b3983 (diff)
downloadglibc-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--CONFORMANCE168
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.