ralf.corsepius at rtems.org
Mon May 7 15:04:32 UTC 2007
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;
> 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
i.e. the exact targets and patches' versions matter in this case.
More information about the users