RE: [patch] Add fast<N>_t types to stdint.h

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On Thu, 2005-09-22 at 12:43 +0200, Schwarz, Konrad wrote:
> > -----Original Message-----
> > From: newlib-owner@sources.redhat.com 
> > [mailto:newlib-owner@sources.redhat.com] On Behalf Of Ralf Corsepius
> > Sent: Thursday, September 22, 2005 11:24 AM
> > To: newlib@sources.redhat.com
> > Subject: Re: [patch] Add fast<N>_t types to stdint.h
> 
> [... Various proposals ...]
> 
> Automatically (i.e., across all architectures) deriving "best" (perhaps
> even "good") definitions for <stdint.h> typedefs is by nature not
> possible; this is precisely the reason this header was introduced by
> C99: it provides new information which is not available in previous
> versions of standard C.
> 
> It seems to me, therefore, that the correct place for the origin of
> these definitions would be in the architecture-specific parts of the
> compiler.
I am inclined to agree, but ... fact is:

GCC expects stdint.h, sys/types.h etc. to be provided externally, either
by libc or by the OS, and so do most libc and OS implementations. At
least I am not aware about any libc/OS implementation not doing so. Also
GCC's reception to any attempts to implement stdint.h etc. inside of it
has been very reluctant, so far.

Implementing stdint.h, sys/types.h etc. al. as part of libc works
sufficiently as long as you don't start to try optimizing.
If you try to do so, you end up in cascades of compiler-,  architecture-
and cpu-variant specific defines and/or machine rsp. os-specific include
files.

That's what RTEMS and Cygwin have done so far with newlib. 
To them it doesn't really matter whether stdint.h is part of newlib or
an OS header, to be added at appropriate places during building the OS
compiler toolchain.

Ralf