Re: uint32_t typedef differences causes issues


Marcus Shawcroft <marcus.shawcroft@...>
 

On 19 January 2017 at 15:39, Anas Nashif <nashif(a)gmail.com> wrote:


On Thu, Jan 19, 2017 at 10:03 AM, Johan Hedberg <johan.hedberg(a)intel.com>
wrote:

Hi Marcus,

On Thu, Jan 19, 2017, Marcus Shawcroft wrote:
The right format specifier for unsigned integers is %u and not %d, so
as
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:
PRIu32

e.g.
#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.
We will likely find either immediately, or with future additions to
/ext that each blob of third party code does something different:
- Some will use %u for uint32_t
- Some will use %lu for uint32_t
- Some might even actually use the inttypes.h defs.
- Some will have hacked the problem already with stuff like "%lu",
(long int) some_uint32_variable
...

Clearly we can't appease the first two simultaneously by futzing with
newlib, gcc etc

If we want to get diagnostic clean from the compiler we may end up
needing to explicitly disable -Wformat on /ext

Cheers
/Marcus

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