[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Mon, 07 May 2007 17:04:32 +0200
- From: ralf.corsepius at rtems.org (Ralf Corsepius)
- Subject: stdint.h question
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.