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.)
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
===================
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 2000-10-08, 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, wint_t or off_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.
The @code{nextafter} function returns the next representable neighbor of
@var{x} in the direction towards @var{y}. The size of the step between
@var{x} and the result depends on the type of the result. If
-@math{@var{x} = @var{y}} the function simply returns @var{x}. If either
+@math{@var{x} = @var{y}} the function simply returns @var{y}. If either
value is @code{NaN}, @code{NaN} is returned. Otherwise
a value corresponding to the value of the least significant bit in the
mantissa is added or subtracted, depending on the direction.