ftp://ftp.rdg.opengroup.org/pub/unsupported/stdtools/hdrchk/
-I've last run the suite on 2000-08-13 on a Linux/ix86 system with the
-following results [*]:
+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 No reported problems
+ XPG3 Prototypes are now in the correct header file
- XPG4 No reported problems
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+*** 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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- POSIX96 Same as for UNIX98 (see below).
- UNIX98 The message queue implementation is missing:
+ UNIX98 Prototypes moved and _POSIX2_C_VERSION removed
+ (using "base realtime threads mse lfs" subset)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-/****** <mqueue.h> - Missing include file ******/
-/****** Start of Definitions for file mqueue.h ******/
-extern int mq_close();
-extern int mq_getattr();
-extern int mq_notify();
-extern mqd_t mq_open();
-extern ssize_t mq_receive();
-extern int mq_send();
-extern int mq_setattr();
-extern int mq_unlink();
-typedef <type> mqd_t;
-struct mq_attr { <members> };
-struct sigevent { <members> };
-/****** End of Definitions for file mqueue.h ******/
+*** 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 splitted limits.h file).
+problems resulting from the split limits.h file).
Technical C standards conformance issues in glibc
Defects in the C99 standard
===========================
-The definition of macros such as INT8_C in <stdint.h> and <inttypes.h>
-is not implementable (Defect Report #209); this is expected to be
-fixed in a Technical Corrigendum to make the macros yield a constant
-expression of the promoted type (for example, int rather than char)
-rather than needing to be able to represent constants of type char.
-glibc follows this corrected version.
-
-Several of the <fenv.h> functions are specified to return void, but
-Defect Report #202 points out that under some circumstances they may
-need to return an error status. They are expected to be corrected to
-return int; glibc follows this corrected specification.
+Some defects in C99 were corrected in Technical Corrigendum 1 to that
+standard. glibc follows the corrected specification.
Implementation of library functions
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.
+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 defined by the
-compiler, and to be constant throughout the translation unit (before
-and after any library headers are included). However, they mainly
-relate to library features, and the necessary magic has yet to be
-implemented for GCC to predefine them to the correct values for the
-library in use, so glibc defines them in <features.h>. Programs that
-test them before including any standard headers may misbehave.
+__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. This has the corresponding impact on
-the relevant headers.
-
-glibc's use of extern inline conflicts with C99: in C99, extern inline
-means that an external definition is generated as well as possibly an
-inline definition, but in GCC it means that no external definition is
-generated. When GCC's C99 mode implements C99 inline semantics, this
-will break the uses of extern inline in glibc's headers. (Actually,
-glibc uses `extern __inline', which is beyond the scope of the
-standard, but it would clearly be very confusing for `__inline' and
-plain `inline' to have different meanings in C99 mode.)
+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
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.) GCC's <float.h> is missing
-FLT_EVAL_METHOD and DECIMAL_DIG; glibc instead provides them in
-<math.h>, which is not what the standard specifies. GCC's <stdbool.h>
-is broken: GCC lacks support for the _Bool type.
+provides <stdint.h>, and GCC doesn't before version 4.5.)
-Implementing MATH_ERRNO, MATH_ERREXCEPT and math_errhandling in
-<math.h> needs compiler support: see
-
-http://sources.redhat.com/ml/libc-hacker/2000-06/msg00008.html
-http://sources.redhat.com/ml/libc-hacker/2000-06/msg00014.html
-http://sources.redhat.com/ml/libc-hacker/2000-06/msg00015.html
+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
===================
-There are various technical issues with the definitions contained in
-glibc's headers. See
-
-http://sources.redhat.com/ml/libc-alpha/2000-07/msg00259.html
-http://sources.redhat.com/ml/libc-alpha/2000-07/msg00279.html
+None known.
projects / thirdparty / glibc.git / blobdiff