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: stdint.h


On Tue, 2005-09-20 at 12:23 +0200, Corinna Vinschen wrote:
> Guys,
> 
> On Sep 20 00:25, Christopher Faylor wrote:
> > On Tue, Sep 20, 2005 at 04:47:27AM +0200, Ralf Corsepius wrote:
> > >On Mon, 2005-09-19 at 22:11 -0400, Christopher Faylor wrote:
> > >>I really don't see any need to use the RTEMS stuff especially given the
> > >>"it's not broke" principle.
> > >
> > >Well, the RTEMS stdint.h/inttypes.h aren't specific to RTEMS.
> > 
> > Again, since there is nothing wrong with the present cygwin
> > implementation, there is no reason to change what we have.

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

>   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.
Check your preprocessed sources:
...
long long arr3[] = {
  INT8_MIN,
  INT16_MIN,
  INT32_MIN,
  INT64_MIN,
...

Preprocessed:
long long arr3[] = {
  -128,
  -32768,
  -2147483648,
  -9223372036854775808,

Also: cat printint.c
#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

int main()
{
  printf( "%" PRId32 "\n", INT32_MIN);
}

Preprocessed:
...
  printf( "%" "d" "\n", -2147483648);
...

./printint
-2147483648

I'd say you've hit a bug in your GCC ;)

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

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

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

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

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



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