]> git.ipfire.org Git - thirdparty/glibc.git/blame - CONFORMANCE
Port the 0x7efe...feff pattern to GCC 6.
[thirdparty/glibc.git] / CONFORMANCE
CommitLineData
107f8131
UD
1Conformance of the GNU libc with various standards
2==================================================
3
4The GNU libc is designed to be conformant with existing standard as
6a3b5b5c 5far as possible. To ensure this I've run various tests. The results
107f8131
UD
6are presented here.
7
8
9Open Group's hdrchk
9df76933 10===================
107f8131
UD
11
12The hdrchk test suite is available from the Open Group at
13
14 ftp://ftp.rdg.opengroup.org/pub/unsupported/stdtools/hdrchk/
15
d7ba1313
UD
16I've last run the suite on 2004-04-17 on a Linux/x86 system running
17a Fedora Core 2 test 2 + updates with the following results [*]:
107f8131
UD
18
19 FIPS No reported problems
20
21 POSIX90 No reported problems
22
d7ba1313 23 XPG3 Prototypes are now in the correct header file
107f8131 24
d7ba1313
UD
25~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
26*** Starting unistd.h
27Missing: extern char * cuserid();
28Missing: extern int rename();
29*** Completed unistd.h
30~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
107f8131 31
d7ba1313
UD
32 XPG4 Prototype is now in the correct header file
33 and the _POSIX2_C_VERSION symbol has been removed
107f8131
UD
34
35~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
d7ba1313
UD
36*** Starting unistd.h
37Missing: extern char * cuserid();
38Missing: #define _POSIX2_C_VERSION (-1L)
39*** Completed unistd.h
107f8131
UD
40~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
41
d7ba1313
UD
42 POSIX96 Prototype moved
43 (using "base realtime threads" subsets)
44
45~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
46*** Starting unistd.h
47Missing: 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
56Missing: extern char * cuserid();
57Missing: #define _POSIX2_C_VERSION (-1L)
58Missing: extern int pthread_atfork();
59*** Completed unistd.h
60~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
61
62
63That means all the reported issues are due to the headers having been
64cleaned up for recent POSIX/Unix specification versions. Duplicated
65prototypes have been removed and obsolete symbols have been removed.
66Which means that as far as the tests performed by the script go, the
67headers files comply to the current POSIX/Unix specification.
68
69
107f8131
UD
70[*] Since the scripts are not clever enough for the way gcc handles
71include files (namely, putting some of them in gcc-local directory) I
72copied over the iso646.h, float.h, and stddef.h headers and ignored the
d7ba1313 73problems resulting from the split limits.h file).
9df76933
UD
74
75
76Technical C standards conformance issues in glibc
77=================================================
78
79If you compile programs against glibc with __STRICT_ANSI__ defined
80(as, for example, by gcc -ansi, gcc -std=c89, gcc -std=iso1990:199409
81or gcc -std=c99), and use only the headers specified by the version of
82the C standard chosen, glibc will attempt to conform to that version
83of the C standard (as indicated by __STDC_VERSION__):
84
85GCC options Standard version
86-ansi ISO/IEC 9899:1990
87-std=c89 ISO/IEC 9899:1990
087722b8 88-std=iso9899:199409 ISO/IEC 9899:1990 as amended by Amd.1:1995
9df76933
UD
89-std=c99 ISO/IEC 9899:1999
90
91(Note that -std=c99 is not available in GCC 2.95.2, and that no
92version of GCC presently existing implements the full C99 standard.)
93
94You may then define additional feature test macros to enable the
95features from other standards, and use the headers defined in those
96standards (for example, defining _POSIX_C_SOURCE to be 199506L to
97enable features from ISO/IEC 9945-1:1996).
98
99There are some technical ways in which glibc is known not to conform
100to the supported versions of the C standard, as detailed below. Some
101of these relate to defects in the standard that are expected to be
102fixed, or to compiler limitations.
103
104
105Defects in the C99 standard
106===========================
107
9718642b
RM
108Some defects in C99 were corrected in Technical Corrigendum 1 to that
109standard. glibc follows the corrected specification.
9df76933
UD
110
111
112Implementation of library functions
113===================================
114
115The implementation of some library functions does not fully follow the
116standard specification:
117
118C99 added additional forms of floating point constants (hexadecimal
119constants, NaNs and infinities) to be recognised by strtod() and
120scanf(). The effect is to change the behavior of some strictly
121conforming C90 programs; glibc implements the C99 versions only
122irrespective of the standard version selected.
123
124C99 added %a as another scanf format specifier for floating point
125values. This conflicts with the glibc extension where %as, %a[ and
126%aS mean to allocate the string for the data read. A strictly
127conforming C99 program using %as, %a[ or %aS in a scanf format string
625c9633
JM
128will misbehave under glibc if it does not include <stdio.h> and
129instead declares scanf itself; if it gets the declaration of scanf
130from <stdio.h>, it will use a C99-conforming version.
9df76933
UD
131
132
133Compiler limitations
134====================
135
136The macros __STDC_IEC_559__, __STDC_IEC_559_COMPLEX__ and
ff3b3d82
JM
137__STDC_ISO_10646__ are properly supposed to be constant throughout the
138translation unit (before and after any library headers are included).
139However, they mainly relate to library features, and GCC only knows to
140preinclude <stdc-predef.h> to get their definitions in version 4.8 and
141later. Programs that test them before including any standard headers
142may misbehave with older compilers.
9df76933
UD
143
144GCC doesn't support the optional imaginary types. Nor does it
0a7fef01
UD
145understand the keyword _Complex before GCC 3.0. This has the
146corresponding impact on the relevant headers.
9df76933 147
9df76933
UD
148glibc's <tgmath.h> implementation is arcane but thought to work
149correctly; a clean and comprehensible version requires compiler
150builtins.
151
152For most of the headers required of freestanding implementations,
153glibc relies on GCC to provide correct versions. (At present, glibc
625c9633
JM
154provides <stdint.h>, and GCC doesn't before version 4.5.)
155
156The definition of math_errhandling conforms so long as no translation
157unit using math_errhandling is compiled with -fno-math-errno,
158-fno-trapping-math or options such as -ffast-math that imply these
159options. math_errhandling is only conditionally defined depending on
160__FAST_MATH__; the compiler does not provide the information needed
161for more exact definitions based on settings of -fno-math-errno and
162-fno-trapping-math, possibly for only some source files in a program.
9df76933
UD
163
164
165Issues with headers
166===================
167
76755a89 168None known.