c/448: <stdint.h>-related issues

[Joseph Myers]

>Number:         448
>Category:       c
>Synopsis:       <stdint.h>-related issues
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Aug 07 07:46:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Joseph S. Myers
>Release:        2.96
>Organization:
none
>Environment:
System: Linux decomino 2.2.16 #1 Thu Jun 8 00:26:22 UTC 2000 i686 unknown
Architecture: i686

	
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
>Description:

This PR is to track the existence of issues that will need to be fixed
for full C99 support, and the reason for some XFAILs.

For printf and scanf format checking to properly support C99 %j
formats, GCC needs an internal notion of the intmax_t and uintmax_t
types, meaning intmax_type_node and uintmax_type_node tree nodes for
appropriate types specified in the target-specific headers.

It also needs to communicate this information somehow to the tests
c99-printf-1.c (which presently has XFAILs for the %j tests) and
c90-printf-2.c (which presently has a generally incorrect definition
of intmax_t but no XFAILSs).

In general, GCC needs to be able to provide a <stdint.h> header, since
this header is required by C99 for conforming freestanding
implementations.

See the thread starting at
<URL: http://gcc.gnu.org/ml/gcc/2000-07/msg00142.html > for discussion
of the associated issues.

If GCC provides a <stdint.h>, then its inclusion in the relevant
testcases seems a reasonable way of providing the definition without
needing more special macros or typedefs.

The thread starting at
<URL: http://gcc.gnu.org/ml/gcc/2000-07/msg00504.html > shows
significant controversy over whether GCC should install the headers
required of freestanding implementations on all targets; in particular
some targets have their own <stddef.h> and <limits.h> which can cause
problems, although glibc knows what headers GCC provides and expects
them to be provided by GCC (but at present has its own <stdint.h>).
The mutual recursion between GCC's <limits.h> and glibc's <limits.h>,
and the more general problems of interaction between <limits.h>
headers to provide where appropriate the additional constants
specified by POSIX but not by the C standard is very confusing and
fragile.

On some targets (e.g. aix64) the ABI can be changed by compiler
options and the headers need to follow.  The existing methods for this
to work with <limits.h> are fragile; on the more unusual targets
(e.g. c4x), GCC's <limits.h> is simply broken.

Conclusion
==========

GCC needs the mechanisms to provide correct <limits.h> and <stdint.h>
headers for use with embedded targets and targets lacking those
headers (especially <stdint.h>) in their C libraries.  In some cases
it might defer to the system headers if correct, but the ability to
interact with system headers knowing what GCC provides on systems
where GCC is the native compiler (e.g. glibc) also seems useful at
present.

Fragile conditionals in the headers to allow for ABI choices by
compiler options seem a bad way to go ahead.  A more promising
approach might be to generate the headers for each multilib.  The
existing mechanisms could run a generation program for each set of
multilib options used; I have some proof-of-concept shell scripts that
will generate limits.h (treating the compiler plus options as a black
box) and most of stdint.h could be created on the same basis (with
hints possibly provided by the compiler, e.g. through preprocessor
defines, where unusual choices of types are made and the types can't
simply be deduced from existing system headers).

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: