Update.
[platform/upstream/glibc.git] / CONFORMANCE
index bfb8291..20a9ae5 100644 (file)
@@ -62,9 +62,11 @@ 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=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.)
 
@@ -127,8 +129,8 @@ 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.  This has the corresponding impact on
-the relevant headers.
+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
@@ -146,9 +148,7 @@ 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; 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.
+FLT_EVAL_METHOD and DECIMAL_DIG.
 
 Implementing MATH_ERRNO, MATH_ERREXCEPT and math_errhandling in
 <math.h> needs compiler support: see
@@ -162,7 +162,28 @@ Issues with headers
 ===================
 
 There are various technical issues with the definitions contained in
-glibc's headers.  See
+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.
 
-http://sources.redhat.com/ml/libc-alpha/2000-07/msg00259.html
-http://sources.redhat.com/ml/libc-alpha/2000-07/msg00279.html
+<wctype.h> should not declare size_t.