stdint.h

[Jeff Johnston]

Ralf Corsepius wrote:
> On Tue, 2005-09-20 at 12:23 +0200, Corinna Vinschen wrote:
>>However, it doesn't even build when using RTMES stdint.h/inttypes.h,
>>so I don't think the RTEMS stdint.h was ready for prime time:
> 
> Well, it survived ca. 1 year of repeated reviews and tests. Apparently
> these reviews have not been very thorough.
> 
> 
>>- A couple of disturbing warnings about INT32_MIN, INT64_MIN, INT64_MAX
>>  and the corresponding unsigned defnitions:
>>
>>   INT32_MIN:  warning: this decimal constant is unsigned only in ISO C90
>>   INT64_MIN:  integer constant is so large that it is unsigned
>>               this decimal constant is unsigned only in ISO C90
>>   INT64_MAX:  integer constant is too large for "long" type
>>   UINT32_MAX: warning: this decimal constant is unsigned only in ISO C90
>>   UINT64_MAX: warning: integer constant is so large that it is unsigned
>>               warning: this decimal constant is unsigned only in ISO C90
>>	       warning: integer constant is too large for "long" type
> 
> True.
>

Fixed.  I have changed the code to use the trick of subtracting 1 from 
negative max_value.  I also fixed the 64 bit constants to either use L 
or LL qualifiers based on the __have_long64 and __have_longlong64 flags.

> 
>>  When uncommenting every other problem in the file, there's also a bug
>>  in evaluating the INT32*_MIN values:
>>
>>    INT32_MIN, INTLEAST32_MIN are printed as the positive value
>>    2147483648, not -2147483648.
>

Fixed per the discussion on the list.

> 
>>- All *LEAST* definitions are incorrect because RTEMS' stdint.h defines
>>  them omitting an underscore after the type:
>>
>>    RTEMS:  INTLEAST8_MIN
>>    SUSv3:  INT_LEAST8_MIN
> 
> Right, this is trivial typo, nobody has tripped so far ...
>

Fixed per Shaun's patch.

> 
>>- The condition, when to include limits.h and when not to include it,
>>  seems not to be foolproof.
> 
> Yes, gcc-4 is not correctly taken into account, which (bogusly) causes
> the compiler to fall back to the non-gcc-3 rules.
> 

Still needs looking at.

> The most severe problem however is elsewhere: The __EXP macro in stdint
> doesn't work as it should for the gcc >= 3 case.
> 

The problem is the #undef __EXP line in stdint.h.  What is happening is 
that the macro doesn't get expanded in the definition of another macro. 
  It gets expanded when that macro is used.  Since the __EXP macro is 
undef'd by the time we use it, it doesn't get expanded, etc... I have 
fixed this by renaming the __EXP macro to __STDINT_EXP (I assume you 
undef'd it as the name may be used elsewhere).  The #undef is removed.

> Jeff, I'd recommend to move this file back to the RTEMS folder. I'll try
> to gradually fix this file.
> 

No longer necessary.  Please feel free to add the missing components 
though :)

> BTW: The only points required by building GCC and RTEMS are the sizes of
> the types, not the limits. That's probably why most of the bugs pointed
> out herein have passed unnoticed so far.
> 
> Ralf
> 
>