190 lines
7.1 KiB
Plaintext
190 lines
7.1 KiB
Plaintext
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
|
|
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 2000-08-13 on a Linux/ix86 system with the
|
|
following results [*]:
|
|
|
|
FIPS No reported problems
|
|
|
|
POSIX90 No reported problems
|
|
|
|
XPG3 No reported problems
|
|
|
|
XPG4 No reported problems
|
|
|
|
POSIX96 Same as for UNIX98 (see below).
|
|
UNIX98 The message queue implementation is missing:
|
|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
/****** <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 ******/
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
[*] 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.
|