This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Fwd: [Bug c/448] Re: stdint.h]


Attached is an explanation that stdint.h should be provided in gcc.

Cheers,
Shaun

--- Begin Message ---
On Thu, 3 Jul 2003, Shaun Jackman wrote:

> Why does gcc leave stdint.h for libc to provide? I'm looking at newlib
> now, and am wondering if newlib should be modified to provide stdint.h,
> or if gcc is the proper home for it (like stdbool.h and others).

GCC should provide it.  Now that cpp is fully integrated into cc1, this
can work by defining lots of internal macros that a single
system-independent <stdint.h> then uses, as for <limits.h> and <float.h>,
so much of the discussion linked to from bug 448 is no longer applicable.
[Note that I'm CC:ing gcc-bugzilla to track this discussion in that bug.]

Note that GCC will need to acquire knowledge of what the target library's
sig_atomic_t is, which previously wasn't necessary.  (See also DR#248:  
some systems may not have a sig_atomic_t at all.)  It will also need to 
know what types are chosen for various of the <stdint.h> types where there 
is a reasonable scope for choice and the target system library already has 
made its choices, including on systems such as Solaris with <inttypes.h> 
but not <stdint.h> (which may need fixincludes work).

That GCC's choice of sig_atomic_t agrees with the system <signal.h> can be 
tested in the testsuite in the same manner as gcc.dg/wchar_t-1.c and 
gcc.dg/wint_t-1.c.

For any <stdint.h> work, be sure to have TC1 to hand along with C99, as
there were significant defects in the original specification.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


--- End Message ---

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]