Re: uint32_t typedef differences causes issues

David Brown

On Fri, Jan 20, 2017 at 04:54:11PM +0000, Daniel Thompson wrote:
On 20/01/17 13:37, Patrik Flykt wrote:
On Fri, 2017-01-20 at 06:21 -0500, Anas Nashif wrote:
the question is if we want to enforce usage of PRI macros.
The de facto standard is unfortunately that %d and %u print integers up
to and including an uint32_t. Enforcing these to be expressed as PRIu32
in Zephyr will be less portable for external and internal developers.
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.

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

"value: %" PRIu32 ", other: %" PRIu32

really suffers in readability, and it'd be nice to avoid if possible.


Join to automatically receive all group messages.