I've needed to port a project to run with Eclipse with its own Makefile. I have modified its makefile, and i guess the error is connected to it or a compiler flag.
Host: Virtualbox Win 8,x64, target device: nrf51822 which is arm cortex-m0. I use gnu arm cross compiler 4.8.4 (GNU Tools ARM Embedded)
Compile shows the following error/warning message:
src/main.c:173:4: error: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint32_t' [-Werror=format=]
I don't understand it. uint32_t is unsigned int in this case. I've included stdint.h.
I compile sources with the following flags:
CFLAGS += -mcpu=cortex-m0 -mthumb -mabi=aapcs --std=gnu11 -funsigned-char -DNRF51 -DDEBUG_NRF_USER -DBLE_STACK_SUPPORT_REQD -DBOARD_PCA10000 -DNRF51822_QFAA_CA
CFLAGS += -Wall -Werror
CFLAGS += -mfloat-abi=soft
Does not -mcpu=cortex-m0 specifies the size of the integer? stdint.h pre-processor macros should generate "typedef unsigned int __uint32_t;". Eclipse shows it that this line is compiled, but i do not know wether to trust it because external makefile is used with its own compiler.
%u
foruint32_t
, even if it has the same size asunsigned int
. So the warning might be justified somehow (although it may be safe to ignore it). – Lionhearted"%" PRIu32
instead of"%u"
. – Zygosporeuint32_t
really is typedefed asunsigned int
then they are exactly the same type. I suspect that the OP is mistaken andunsigned int
isn't 32 bits. Printingsizeof(unsigned int)
would confirm. – Contestationsizeof(unsigned int) * CHAR_BIT
would confirm even more. – Zygosporesizeof(uint32_t) == sizeof(unsigned)
doesn't imply that they are aliases, they both could be typedefs to some built-in type, as I read the standard, and they both could be different types (similar to howchar
may be likesigned char
but a different type). I'm curious if such a warning would be justified even on systems withsizeof(uint32_t) == sizeof(unsigned int)
... – Lionheartedint
andunsigned int
are "corresponding types". The standard does indeed allow multiple integer types of the same size that aren't compatible, although I don't think there is any such thing in existence and it seems like a bad idea. "similar to how char may be like signed char but a different type" -- but the standard says "The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char" so passing any of them to %c is safe. – Contestation