X-Git-Url: http://git.csclub.uwaterloo.ca/?p=kopensolaris-gnu%2Fglibc.git;a=blobdiff_plain;f=CONFORMANCE;h=68723086cc89204e5ebf65e35777f7022cdb4471;hp=cf00caa4d9fe8d17edaf32ebac6f0e1309e7694c;hb=4b69b20a6f55e974e80e2eff97f0c79257673d5e;hpb=dceeb9c8db15890ab480a42ae641d655270f48db;ds=sidebyside diff --git a/CONFORMANCE b/CONFORMANCE index cf00caa4d9..68723086cc 100644 --- a/CONFORMANCE +++ b/CONFORMANCE @@ -7,121 +7,169 @@ 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 1998-07-08 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 The wide character I/O stuff is missing in glibc. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +*** 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 wchar.h -Missing: extern wint_t fgetwc(); -Missing: extern wchar_t *fgetws(); -Missing: extern wint_t fputwc(); -Missing: extern int fputws(); -Missing: extern wint_t getwc(); -Missing: extern wint_t getwchar(); -Missing: extern wint_t putwc(); -Missing: extern wchar_t putwchar(); -Missing: extern wint_t ungetwc(); -Missing: extern size_t wcsftime(); -*** Completed wchar.h +*** Starting unistd.h +Missing: extern char * cuserid(); +Missing: #define _POSIX2_C_VERSION (-1L) +*** Completed unistd.h ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Beside this a problem in stdio.h is reported but - this is only because the scripts don't understand - the sometimes complex constructs in the header. + POSIX96 Prototype moved + (using "base realtime threads" subsets) - POSIX96 Same as UNIX98 [see below]. - UNIX98 Quite a lot of problems, almost all due to limitations - of the Linux kernel (2.1.108): +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +*** 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 mqueue.h -Missing #include file: mqueue.h -*** Completed mqueue.h -*** Starting semaphore.h -Missing: #define SEM_FAILED (-1) -Missing: extern int sem_close(); -Missing: extern sem_t *sem_open(); -Missing: extern int sem_unlink(); -*** Completed semaphore.h -*** Starting signal.h -Missing: #define SIGSYS (-1) -*** Completed signal.h -*** Starting sys/mman.h -Missing: extern int shm_open(); -Missing: extern int shm_unlink(); -*** Completed sys/mman.h -*** Starting sys/stat.h -Missing: #define S_TYPEISMQ (-1) -Missing: #define S_TYPEISSEM (-1) -Missing: #define S_TYPEISSHM (-1) -*** Completed sys/stat.h -*** Starting sys/types.h -Missing: typedef clockid_t; -Missing: typedef timer_t; -*** Completed sys/types.h -*** Starting time.h -Missing: #define CLOCK_REALTIME (-1) -Missing: #define TIMER_ABSTIME (-1) -Missing: extern int clock_getres(); -Missing: extern int clock_gettime(); -Missing: extern int clock_settime(); -Missing: struct itimerspec { }; -Missing: extern int timer_create(); -Missing: extern int timer_delete(); -Missing: extern int timer_getoverrun(); -Missing: extern int timer_gettime(); -Missing: extern int timer_settime(); -*** Completed time.h *** Starting unistd.h -Missing: #define _POSIX_MESSAGE_PASSING (-1) -Missing: #define _POSIX_SEMAPHORES (-1) -Missing: #define _POSIX_SHARED_MEMORY_OBJECTS (-1) -Missing: #define _POSIX_TIMERS (-1) +Missing: extern char * cuserid(); +Missing: #define _POSIX2_C_VERSION (-1L) +Missing: extern int pthread_atfork(); *** Completed unistd.h -*** Starting wchar.h -Missing: extern wint_t fgetwc(); -Missing: extern wchar_t *fgetws(); -Missing: extern wint_t fputwc(); -Missing: extern int fputws(); -Missing: extern int fwide(); -Missing: extern int fwprintf(); -Missing: extern int fwscanf(); -Missing: extern wint_t getwc(); -Missing: extern wint_t getwchar(); -Missing: extern wint_t putwc(); -Missing: extern wchar_t putwchar(); -Missing: extern int swprintf(); -Missing: extern int swscanf(); -Missing: extern wint_t ungetwc(); -Missing: extern int vfwprintf(); -Missing: extern int vswprintf(); -Missing: extern int vwprintf(); -Missing: extern size_t wcsftime(); -Missing: extern wchar_t *wcswcs(); -Missing: extern int wprintf(); -Missing: extern int wscanf(); -*** Completed wchar.h ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - Only the `wchar.h' problems result from glibc - defficiencies since we still don't support wide - character I/O. + +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 +================================================= + +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. + + +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 . Programs that +test them before including any standard headers may misbehave. + +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 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.) + +glibc's 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 , and GCC doesn't.) + +Implementing MATH_ERRNO, MATH_ERREXCEPT and math_errhandling in + 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 + + +Issues with headers +=================== + +None known.