There is a difference between strictly being compliant and doing what makes
From the error printout, my first conclusion is that there is a bug inI don't think there's anything wrong with newlib. The only requirement
newlib, not the other way around.
on the C library is that uint32_t is 32-bits wide (i.e. no padding) and
the newlib implementation meets this requirement.
things easier for the users. I would gather that most users would expect a
uint32_t to be printable with %d, and we have a fairly easy way to make that
Changing the type of uint32_t to match expectations will still be compliant
with C standards, and make life easier for users.
I don't have any problem with changing minimal libc to have the same definitions as newlib.
Zephyr itself can use PRIu32 internally both to avoid warnings and toDo we expect Zephyr to ever be ported to 16-bit targets? If so, this might
be maximally portable (i.e. conforming to C99).
make sense. Otherwise, I think we should meet the expectations most
programmers will have that 32-bit values can be printed with a %d.
"value: %" PRIu32 ", other: %" PRIu32
really suffers in readability, and it'd be nice to avoid if possible.
I can't say one way or another whether we will end up supporting 16-bit targets but I think we should do the correct thing.
I feel claims that this ruins code readability are overstated.