From the error printout, my first conclusion is that there is a bug in newlib, not the other way around.
I don't think there's anything wrong with newlib. The only requirement on the C library is that uint32_t is 32-bits wide (i.e. no padding) and the newlib implementation meets this requirement.
There is a difference between strictly being compliant and doing what makes 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 work.
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 to be maximally portable (i.e. conforming to C99).
Do we expect Zephyr to ever be ported to 16-bit targets? If so, this might 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.
