Update.
[platform/upstream/glibc.git] / CONFORMANCE
index c0e8f6b..20a9ae5 100644 (file)
@@ -2,18 +2,18 @@ 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
+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 1998-07-08 on a Linux/ix86 system with the
+I've last run the suite on 2000-08-13 on a Linux/ix86 system with the
 following results [*]:
 
        FIPS            No reported problems
@@ -22,106 +22,168 @@ following results [*]:
 
        XPG3            No reported problems
 
-       XPG4            The wide character I/O stuff is missing in glibc.
+       XPG4            No reported problems
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-*** 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
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-                       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         Same as UNIX98 [see below].
-       UNIX98          Quite a lot of problems, almost all due to limitations
-                       of the Linux kernel (2.1.108):
+       POSIX96         Same as for UNIX98 (see below).
+       UNIX98          The message queue implementation is missing:
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-*** 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        <type>  clockid_t;
-Missing: typedef        <type>  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 { <members> };
-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)
-*** 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
+/****** <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 ******/
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-                       Only the `wchar.h' problems result from glibc
-                       defficiencies since we still don't support wide
-                       character I/O.
-
 [*] 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).
+
+
+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
+
+* glibc does not support this standard version.
+
+(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
+===========================
+
+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.
+
+
+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 <features.h>.  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 <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.)  GCC's <float.h> is missing
+FLT_EVAL_METHOD and DECIMAL_DIG.
+
+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
+
+
+Issues with headers
+===================
+
+There are various technical issues with the definitions contained in
+glibc's headers, listed below.  The list below assumes current CVS GCC
+as of 2001-01-10, and relates to i686-linux; older GCC may lead to
+more problems in the headers.
+
+Note that the _t suffix is reserved by POSIX, but not by pure ISO C.
+Also, the Single Unix Specification generally requires more types to
+be included in headers (if _XOPEN_SOURCE is defined appropriately)
+than ISO C permits.
+
+<ctype.h> should not declare size_t.
+
+<inttypes.h> should not declare wchar_t.
+
+<signal.h> should not declare size_t.
+
+<stdint.h> should not declare wchar_t.
+
+<stdio.h> should not declare or use wchar_t or wint_t.
+
+<wchar.h> does not support AMD1; to support it, the functions
+fwprintf, fwscanf, wprintf, wscanf, swprintf, swscanf, vfwprintf,
+vwprintf, vswprintf and fwide would need to be declared when
+__STDC_VERSION__ >= 199409L and not just for C99.
+
+<wctype.h> should not declare size_t.