stdint.h question

[Ralf Corsepius]

On Mon, 2007-05-07 at 07:54 -0700, Till Straumann wrote:
> Ralf Corsepius wrote:
> > On Wed, 2007-05-02 at 20:14 -0700, Till Straumann wrote:
> >   
> >> Who has not encountered those (and other annoying)
> >> warnings:
> >>
> >>  > warning: format '%x' expects type 'unsigned int', but argument 6 has 
> >> type 'uint32_t'
> >>
> >> e.g., under linux (glibc) I don't get those but when porting code
> >> to RTEMS I do. linux' stdint.h defines uint32_t as 'unsigned int'
> >> (on a 32-bit machine) but RTEMS/newlib as 'unsigned long'.
> >> (BTW: freebsd also uses int / unsigned int for int32_t / uint32_t
> >> [i386, powerpc]).
> >>     
> > All random accidents. All such code doesn't comply to the standards.
> >
> >   
> >> Does anybody have an idea how to properly deal with this?
> >>     
> > Use the macros from inttypes.h.
> >   
> You are right, thx.
> Unfortunately, there still seems to be a bug in the newlib headers:
> Compiling the snippet
> 
> #include <inttypes.h>
> #include <stdio.h>
> 
> uintptr_t blah(void *arg)
> {
> uintptr_t rval = (uintptr_t)arg;
>     printf("%"PRIxPTR"\n", rval);
>     return rval;
> }
> 
> produces:
> 
> tst.c: In function 'blah':
> tst.c:7: warning: format '%llx' expects type 'long long unsigned int', 
> but argument 2 has type 'uintptr_t'
> 
> I.e., the formatting macro expands to 'unsigned long long int' but 
> uintptr_t is only 'unsigned int'
> (which seems to be ok on a 32-bit machine).
> 
> (gcc 4.1.1, newlib 1.14.0)

Which target, which RTEMS patches versions?

There had been a couple of bug in vanilla newlib's implementation which
had (occasionally) affected a couple of targets (esp. 16 bit
plattforms), which now are supposed to be fixed in current rtems
toolchains.

i.e. the exact targets and patches' versions matter in this case.

Ralf