Re: uint32_t typedef differences causes issues


Boie, Andrew P
 

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.

Andrew

Join devel@lists.zephyrproject.org to automatically receive all group messages.