Set errno for ±Inf.
[glibc/history.git] / CONFORMANCE
blob68723086cc89204e5ebf65e35777f7022cdb4471
1 Conformance of the GNU libc with various standards
2 ==================================================
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.
9 Open Group's hdrchk
10 ===================
12 The hdrchk test suite is available from the Open Group at
14         ftp://ftp.rdg.opengroup.org/pub/unsupported/stdtools/hdrchk/
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 [*]:
19         FIPS            No reported problems
21         POSIX90         No reported problems
23         XPG3            Prototypes are now in the correct header file
25 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
26 *** Starting unistd.h
27 Missing: extern char *  cuserid();
28 Missing: extern int     rename();
29 *** Completed unistd.h
30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
32         XPG4            Prototype is now in the correct header file
33                         and the _POSIX2_C_VERSION symbol has been removed
35 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
36 *** Starting unistd.h
37 Missing: extern char *  cuserid();
38 Missing: #define        _POSIX2_C_VERSION       (-1L)
39 *** Completed unistd.h
40 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
42         POSIX96         Prototype moved
43                         (using "base realtime threads" subsets)
45 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
46 *** Starting unistd.h
47 Missing: extern int     pthread_atfork();
48 *** Completed unistd.h
49 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
51         UNIX98          Prototypes moved and _POSIX2_C_VERSION removed
52                         (using "base realtime threads mse lfs" subset)
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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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.
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).
76 Technical C standards conformance issues in glibc
77 =================================================
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__):
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
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.)
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).
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.
105 Defects in the C99 standard
106 ===========================
108 Some defects in C99 were corrected in Technical Corrigendum 1 to that
109 standard.  glibc follows the corrected specification.
112 Implementation of library functions
113 ===================================
115 The implementation of some library functions does not fully follow the
116 standard specification:
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.
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.
131 Compiler limitations
132 ====================
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.
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.
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.)
156 glibc's <tgmath.h> implementation is arcane but thought to work
157 correctly; a clean and comprehensible version requires compiler
158 builtins.
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.)
164 Implementing MATH_ERRNO, MATH_ERREXCEPT and math_errhandling in
165 <math.h> needs compiler support: see
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
172 Issues with headers
173 ===================
175 None known.