Hi Cary,
On Apr 27 22:52, Cary R. wrote:
> The following code:
>
> #include <stdio.h>
> #include <inttypes.h>
>
> int main()
> {
> int32_t ival = 1;
> uint32_t uval = 2;
>
> printf("int = %"PRId32", uint = %"PRIu32".\n", ival, uval);
> return 0;
> }
>
>
> when compiled with either gcc or clang on a 32-bit system and with the -Wall
> flag produces the following warnings:
>
> tmp.c: In function ‘main’:
> tmp.c:9:5: warning: format ‘%ld’ expects argument of type ‘long int’, but
> argument 2 has type ‘int32_t’ [-Wformat=]
> printf("int = %"PRId32", uint = %"PRIu32".\n", ival, uval);
> ^
> tmp.c:9:5: warning: format ‘%lu’ expects argument of type ‘long unsigned
> int’, but argument 3 has type ‘uint32_t’ [-Wformat=]
> tmp.c:9:5: warning: format ‘%ld’ expects argument of type ‘long int’, but
> argument 2 has type ‘int32_t’ [-Wformat=]
> tmp.c:9:5: warning: format ‘%lu’ expects argument of type ‘long unsigned
> int’, but argument 3 has type ‘uint32_t’ [-Wformat=]
>
> I'm not sure why the double report for this, but both gcc and clang do
> the same thing. This looks to be an issue that is generated because a
> long is 32 bits on a 32-bit system and in inttypes.h __have_long32 is
> likely defined and that is forcing the use of the 'l' formats when
> that is incorrect for at least these two 32 bit types.That looks like the culprit, yes. This is part of the newlib changes to stdint.h/inttypes.h, and this is apparently a problem. Just because long is a 32 bit type doesn't mean it's the base type of int32_t/uint32_t. What bugs me most is that I tried to test the changes and failed to see this problem. Grr. I'll discuss this on the newlib mailing list. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpQF8iJEJmvc.pgp
Description: PGP signature
