Incompatible (u)intptr_t type and PRIxPTR definitions

[stephanosio]

Describe the bug
For some platforms, the intptr_t and uintptr_t types do not match the PRIxPTR types.

To Reproduce
On an x86-64 host, build the following code for native_posix board using LLVM (ZEPHYR_TOOLCHAIN_VARIANT=llvm).

uintptr_t val = 1234;
printk("%" PRIuPTR "\n", val);

See the following error:

error: format specifies type 'unsigned int' but the argument has type 'uintptr_t' (aka 'unsigned long') [-Werror,-Wformat]

Expected behavior
The types of intptr_t and uintptr_t and the PRIxPTR match.

For instance:

• If intptr_t is int, PRIdPTR should be %d.
• If intptr_t is long, PRIdPTR should be %ld.

Impact
Makes PRIxPTR useless on the affected platforms (in particular, native_posix on x86-64 with Clang/LLVM).

Environment (please complete the following information):

• OS: Ubuntu 20.04 x86-64
• Toolchain: Clang 10.0 (also tested on Clang 12 and the problem persists)
• Commit SHA: feb0e9f

Additional context
This happens because zephyr_stdint.h re-defines __INTPTR_TYPE__ and __UINTPTR_TYPE__ as long int and long unsigned int, respectively, while the PRIxPTR definitions stay %x with no size prefix.

zephyr/include/toolchain/zephyr_stdint.h

Lines 47 to 50 in feb0e9f

	#undef __INTPTR_TYPE__
	#undef __UINTPTR_TYPE__
	#define __INTPTR_TYPE__ long int
	#define __UINTPTR_TYPE__ long unsigned int

See #37712 (comment).
See also #16645.

[stephanosio]

TODO: Further investigate all the affected platforms/toolchains and make a list of them.
NOTE: Also improve test coverage so that we do not end up with things like this ...

p.s. This should really be fixed before we release LTS.

[stephanosio]

cc @npitre @andyross @pfalcon @galak @nashif @carlescufi @mnkp @pabigot @dcpleung

[npitre]

LLVM is wrong. On a 64-bits platform, a pointer is wider than an unsigned int.

In lib/libc/minimal/include/inttypes.h we have:

#define PRIuPTR                 "lu"

What lib are you using?

[stephanosio]

LLVM is wrong. On a 64-bits platform, a pointer is wider than an unsigned int.

@npitre Building native_posix is with -m32, so pointer should be/is by default int.

For native_posix_64 (which builds with -m64), it will be long.

What lib are you using?

In case of native_posix, it builds with the host Clang (with -m32).

[stephanosio]

This might give better a overview of the issue seen on native_posix with LLVM:
https://gist.github.com/stephanosio/01d70f08046dc979ff7c1de5aab9ea4e

p.s. It looks like, in case of native_posix with host GCC, it does not use the __INTPTR_TYPE__ definition and just typedefs intptr_t to int.

[npitre]

Building native_posix is with -m32, so pointer should be/is by default int.
For native_posix_64 (which builds with -m64), it will be long.

A while ago, we had many problems like that. Commit f32330b fixed
most of them. Zephyr is a young hosting environment so it is in a position
to dictate its types and avoids such legacy shortcomings.

So int32_t is always an int, intptr_t is always a long, and PRIuPTR is
always "lu", for all supported architectures.

Now the native_posix target is a special cases as it runs inside another
environment. Still, the native_posix environment should be isolated as
much as possible so to preserve the Zephyr conventions for Zephyr specific
code.

[stephanosio]

The scope of this issue might be limited to the POSIX arch boards, but I somehow doubt that because we have other third-party toolchains like Arm Compiler and ARC MWDT with their own headers (by the way, cc @tejlmand @abrodkin @evgeniy-paltsev).

I don't have time to do an in-depth analysis on this at the moment. I will revisit this later and do full analysis.

[de-nordic]

There is also problem of definitions like __UINTPTR_MAX__ that do not get override.
The zephyr/include/toolchain/zephyr_stdint.h actually overrides all types by #undef and #define but does nothing to do the same with *_MAX *_MIN definitions, so you may end up with having those mismatched with type.

[pfalcon]

Now the native_posix target is a special cases as it runs inside another
environment. Still, the native_posix environment should be isolated as
much as possible so to preserve the Zephyr conventions for Zephyr specific
code.

I definitely second the sentiment that native_posix breaks a lot the fun. I had a lot of issues with it while working on POSIX subsys: #13054 . And I also eyeballed "radical" solutions like saying that POSIX subsys simply isn't supported on native_posix. Of course, I never went forward with that and exactly tried to "isolate" native_posix stuff from Zephyr's POSIX, but that was quite a swamp (and never finished). Of course, here it's much more focused matter, and maybe it will be possible to make it reach the sweet spot. But given concerns of supporting additional toolchain types raised above, maybe it would just make sense to (re)embrace the fact that these definitions belong to a toolchain, not Zephyr...

(Just thinking aloud really, my 2 cents.)