On Fri, Jan 20, 2017 at 04:54:11PM +0000, Daniel Thompson wrote:
On 20/01/17 13:37, Patrik Flykt wrote:There is a difference between strictly being compliant and doing whatOn Fri, 2017-01-20 at 06:21 -0500, Anas Nashif wrote:From the error printout, my first conclusion is that there is a bug inthe question is if we want to enforce usage of PRI macros.The de facto standard is unfortunately that %d and %u print integers up
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 toDo 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.