Enforce C99 inttypes usage for standard C functions

[stephanosio]

Is your enhancement proposal related to a problem? Please describe.

Zephyr currently overrides the toolchain default C99 integer types ([u]intN_t) to fixed types such that int32_t can always be processed without a size modifier, and int64_t with ll size modifier.

This "hack," introduced in #16645, has caused various toolchain compatibility issues (e.g. #37712 (comment)) and will not be sustainable as we start adding more non-GNU toolchains as supported toolchains for Zephyr -- note that __INT32_TYPE__ and its friends defined by zephyr_stdint.h are non-standard and the toolchain default C library is not obliged to set up the type system using these.

Describe the solution you'd like

Stop re-defining the toolchain default types (i.e. remove zephyr_stdint.h) and always use the C99 inttypes macros with the C99 integer types; e.g.:

int32_t val;

printf("val = %d", val);        /* Incorrect */
printf("val = %" PRId32, val);  /* Correct */

int64_t val;

printf("val = %lld", val);      /* Incorrect */
printf("val = %" PRId64, val);  /* Correct */

For this, the following changes need to be implemented:

• Rework the minimal libc inttypes.h to not assume the fixed types defined by zephyr_stdint.h; the size modifiers need to be resolved based on the native toolchain types.
• Fix all discrete size modifier used with the C99 integer types to use the C99 inttypes macros.
• Remove zephyr_stdint.h.

Additional context

It may be useful to go over the following related issues:

• Incompatible (u)intptr_t type and PRIxPTR definitions #37718
• (U)INT{32,64}_C macro constants do not match the Zephyr stdint types #44199
• newlib: PRIx8 inttype incorrectly resolves to hh with newlib-nano #45336
• Avoid redefining 32-bit integer types like __UINT32_TYPE__ #45248

[stephanosio]

cc @npitre @keith-packard @pfalcon @andyross @dcpleung @carlescufi @tejlmand

[andyross]

Just to record for posterity: I hate the ISO PRI* macro nonsense with a fiery passion. It's ridiculous-looking and hard to read, it takes a perfectly working API with perfectly working error reporting and introduces line noise syntax not for correctness[1], but for portability. And that's just the Wrong Thing. Let code manage the build problems that result, if there are platform-dependent sizes in printf format strings then it's the programmer's job to make sure they aren't used[2].

I won't -1 this. I won't stand in the way of a merge. But this is just awful. We're now committing to explaining to generations of new developers why Zephyr's printf and logging layers are awful. And they're all going to ask "Why doesn't Linux have this problem?!". What's our answer going to be?

[1] There's no typesafety problem with passing e.g. a "int64_t" to a "%ld" on arm64, for example. The compiler knows the types, it knows how to pass a 64 bit argument, it knows how big a "long" is, and it can trivially (and does!) emit a printf format error on i386 builds. Why is that a problem? If the user wrote non-portable code they should fix it. They don't need new (and bad!) syntax in the language to help with that.

[2] e.g. By using %lld in the first place to ensure the full 64 bit value is printed, or by deliberately downconverting a value to 32 bits, etc... Those decisions are application decisions! The printf library can't make them for us, and it shouldn't try.

[stephanosio]

While I am not a very big fan of this either, this is the only way to be portable across different compilers and we have no option but to do this, especially as we start introducing more non-GNU compiler support to the Zephyr.

I believe this is an inevitable decision for us.

p.s. It is as simple as, if you want to use C99 integer types (int32_t, ...), you will have to use the corresponding C99 integer type format specifier macros (PRId32, ...) too.

[andyross]

"But why doesn't Linux need this?" :)

[npitre]

Just to record for posterity: I hate the ISO `PRI*` macro nonsense with a fiery passion.

Amen. I'm 100% with you.

[stephanosio]

"But why doesn't Linux need this?" :)

Because they use their own type system? (u32, ...)

We can go back to doing that again; but, as long as we are using the C99 integer types, we will have to use the corresponding C99 integer type format specifiers too.

[npitre]

as long as we are using the C99 integer types, we will have to use the corresponding C99 integer type format specifiers too.

C99 integer types aren't the problem. The basic types to which they're mapped is. Make int32_t onto an int and int64_t onto a long long at the toolchain level and you'll be fine. That's trivial to accomplish there. The alternative is way more painful and far more work for everyone.

…

-- Reply to this email directly or view it on GitHub: #46032 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>