Re: Fix <stdint.h> bugs

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

Comments interspersed

On Fri, 2008-11-28 at 14:03 +0000, Joseph S. Myers wrote:
> newlib's <stdint.h> has a series of failures to conform to C99.  This
> patch fixes them; in some cases it uses macros that are proposed for
> GCC 4.5 with my patch
> <http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00305.html> to get
> correct values and types in all cases with new enough compilers,
> falling back where possible to definitions as good as possible for
> earlier compilers.
> 
> * 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.

Conversely, I consider the fact newlib in general prefers "long" to be a
"minor defect" newlib has inherited from it's pre-C99/SUSv3's past,
where resorting to longs often had been convenient resort to avoid
"#ifdef/typedef" cascades.

> * 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. 

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.

> * Limits of intmax_t and uintmax_t were not defined.
Right, these were missing. IIRC, the reason had been problems in
deriving them from GCC internal defines with older GCCs.

> * SIZE_MAX and the limits of ptrdiff_t were often of the wrong types;
>   there's a lot of variation between targets on whether these types
>   are "unsigned long" and "long", or "unsigned int" and "int", where
>   those are the same width.
Known issue, ... we have a set of patches to newlib in RTEMS which are
supposed to work around this issue ...

> * Limits of wchar_t and wint_t were not defined.
Right, same rationale as wrt. intmax_t.

> * 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."


> OK to commit?
I would suggest to cut this patch into smaller chunks.

I agree with the intmax_t, ptrdiff_t, wchar_t, wint_t parts of your
proposal. The "limits for [u]int32_t and [u]int_least32" part to me
seems a matter of personal preference, but the "UINT8_C and UINT16_C"
part needs further explanation.

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

Ralf