Hello,

On Wed, 19 Apr 2017 11:32:45 -0500
Kumar Gala <kumar.gala@linaro.org> wrote:

Since the C-std {u}int{8,16,32,64}_t gets us into issues with
supporting different libc across the various architectures since
compilers seem to vary greatly in how the define these types, I
suggested to the Zephyr TSC and got approval that we should move to
our own internal defined size types.

I’m suggesting that we make the following conversion:

int{8,16,32,64}_t -> s{8,16,32,64}_t
uint{8,16,32,64}_t -> u{8,16,32,64}_t

(The _t is to deal with some places that that u8, and u16 are getting
used as variable names.)

Let the bikeshedding now begin.

So, Zephyr being an OS, is in good position to define its own "world
model", like basic value types, and maybe even nobody call that "NIH".
But that would rather have been done at the start of the project.

But now, just imagine what kind of sweeping changes will be to convert
the codebase to these. And one of the concerns with PRI macros
conversion was a similar nature of them, but they're at much smaller
scale. (I understand that the biggest concern should be that people
will keep forgetting to use PRI macros going forward).

And just think about the fact that truly standard uint32_t, etc. types
are a big achievement of the C community - everybody loves them, they
achieved the true developer mindshare penetration, almost every modern
project uses them. And we're discussing how to go from that back to
dark ages. We won't be able to forget about uint32_t anyway, again,
it's the standard, we'll need to do gazillion of casts when interfacing
with 3rd-party libs, and these start from things like SoC vendor HALs.
(Again, ain't it amazing that even vendors who get out of their way to
do it differently from other vendors, actually all standardized on
uint32_t and friends?)

It so happened that I had a similar case with another project some time
ago. And I passed thru all the stages already, from humorous denial of
the problem to outrage that "they" made me go thru all this, so I very
well understand the current discussion ;-). The eventual logical
conclusion was however that if software portability is important, then
the printing question can't be discounted. And then the way C99
defined it is clearly optimized to avoid runtime overhead, which is
also hard to blame in the context of Zephyr (and as we know, embedded
programming was one of the biggest stakeholder behind uint32_t, so it
would be strange if the standard committee didn't think about runtime
overhead of adding full-fledged support for stdint.h).

Summing up, my opinion is that we should try to reconcile the point of
view that PRI is literally unalienable part of uint32_t. If we love the
latter, we should embrace the former too.

Trying to drop it all in 2017, and at such later stage of the project
doesn't sound like a great move for me. If the biggest concern about
perceived "ugliness" of including PRIxxx in format strings, there's
still a potential option of introducing custom, Zephyr-specific
formatting codes, at least to printk() and logging functions,
potentially to printf() too.

(But it may be more a problem with compiler warnings than with
implementation, which is an overall problem - compilers have become
way too smart to let people just do their programming job.)


--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog