This is the mail archive of the newlib@sourceware.org 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]

Re: Fix <stdint.h> bugs


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


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