Re: uint32_t typedef differences causes issues

Johan Hedberg

Hi Anas,

On Thu, Jan 19, 2017, Anas Nashif wrote:
On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
far as I see that's the issue and using %u should make the error go
Since the type is 'uint32_t' rather than 'unsigned' the correct
specifier is:

#include <stdint.h>
printf("blah %" PRIu32 " more blah", v);
Does "correct" in this case have any practical significance? It worsens
the readability of the code quite a lot IMO, so if the significance is
purely theoretical it's a quite high price to pay for correctness. I've
used the PRI* macros in other projects, but never for anything smaller
than 64 bit integers.

We need to take into consideration 3rd party code that we can't modify, so
while it might work for the kernel code, we will still have issues with 3rd
party code using %u.
I'd just like to add to this that while working with Linux and BlueZ
we've used %u extensively for uint8_t, uint16_t and uint32_t without any
issues (I'd think those projects have been run on a larger set of
architectures and C libraries than what Zephyr supports). The only case
where we've had resort to PRI* is uint64_t, and if you check the actual
definition of these in your /usr/include/inttypes.h you'll see that it's
the only one that evaluates to something else than just "u".

Generally I'm a big fan of doing things correctly & properly, but this
stuff just uglifies the format strings too much IMO :)


Join to automatically receive all group messages.