Fix <stdint.h> bugs
Joseph S. Myers
joseph@codesourcery.com
Wed Dec 3 16:04:00 GMT 2008
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, despite the C99 requirements that the limit
macros expand to values with the correct type converted according to the
integer promotions? 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.
> 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.
> > * 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.
The macros must expand to a value with the relevant type *as converted
according to the integer promotions*. And unsigned types narrower than
int promote to int.
> > OK to commit?
> I would suggest to cut this patch into smaller chunks.
Splitting it up significantly complicates the fixincludes changes in GCC,
since matching one comment is no longer enough to detect whether fixes may
need to be applied. For that reason I'd like to avoid the existence of
newlib versions with only a subset of the changes.
> Furthermore, this all is very likely to break details somewhere and
> therefore needs extensive testing.
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. Note that the patch does not change
any type definitions, and by making the logic for limit macros match that
for the corresponding type definitions more closely it makes the header
much easier to check by inspection than it presently is.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Newlib
mailing list