Fix <stdint.h> bugs

[Ralf Corsepius]

On Mon, 2008-12-01 at 13:36 +0000, Joseph S. Myers wrote:
> On Mon, 1 Dec 2008, Ralf Corsepius wrote:
> 
> > > * The limits for [u]int32_t and [u]int_least32_t were defined to "int"
> > >   / "unsigned int" values even when newlib generally prefers "long" /
> > >   "unsigned long" for those types when both are the same width.
> > This is intentional, because that's what I think things should be.
> 
> You think that INT32_MAX should expand to a value with type "int" even 
> when int32_t is of type long, 
No. I am saying, INT32_MAX etc. should expand to the sizes corresponding
to the type int32_t expands. Provided the fact there are targets for
which int and long are not equivalent, not mixing up ints with longs
rsp. their sizes should be the preferable approach.

>   This is the bug I am fixing.
> 
> > > * The limits for the "fast" types did not agree with the logic
> > >   generally preferring "int" for those types.
> > I don't understand what you are trying to say. 
> 
> INT_FAST8_MAX was defined to INT8_MAX when int_fast8_t was defined to int 
> (and so INT_MAX would have been the correct value), for example.
OK.

> > The types being used for "fast" types in newlib is more or less
> > arbitrary, because newlib doesn't know which types actually qualify as
> > "really fast" on a particular target/in a particular use-case.
> 
> However, the limit macros for the fast types need to agree with the types 
> themselves.
Should be so, however then I wonder which bug you're actually fixing,
because I had tested this "to death" before submitting stdint.h to
newlib.

> > > * UINT8_C and UINT16_C wrongly expanded to unsigned values. If the
> > >   types uint_least8_t and uint_least16_t are narrower than int, they
> > >   promote to signed int, and so these macros should expand to signed
> > >   values.
> > Hmm? Why should they promote to signed int?
> > 
> > SUSv3 says:
> > "The macro UINTN_C( value) shall expand to an integer constant
> > expression corresponding to the type uint_least N _t."
> 
> See the definition of "corresponding to the type" as added in C99 TC1. 
URL?

> > Furthermore, this all is very likely to break details somewhere and
> > therefore needs extensive testing.

Then let me answer this way: I need to dig out the testsuite, I had used
to check stdint.h with the rtems toolchains, to gain some more
confidence into your patch.

> It has been tested on arm-none-eabi with the testcases added by my GCC 
> patch.  I suspect a lot of the logic in the header does not apply to any 
> supported toolchain configuration. 
This is what I eagerly hope for.

Ralf