stdint.h: make redefinition of stdint types optional

[mnkp]

PR #16645 streamlined stdint.h type definitions. This has an unfortunate side effect that any legacy code which assumed default, compiler provided types will now generate warnings any time type mismatch is detected during the compilation process. Redefining stdint types also significantly increases porting effort when building an existing bare metal application with Zephyr.

This PR makes redefinition of stdint types optional.

I wasn't sure if the Kconfig option should go into "C library" or "Compiler Options" sub menu. For now it's in the "C library".

[npitre]

On Fri, 18 Oct 2019, Piotr Mienkowski wrote: PR #16645 streamlined stdint.h type definitions. This has an unfortunate side effect that any legacy code which assumed default, compiler provided types will now generate warnings any time type mismatch is detected during the compilation process. Redefining stdint types also significantly increases porting effort when building an existing bare metal application with Zephyr.

The default, compiler provided types are not consistent across compiler versions nor different target architectures already. Furthermore, without this, code that happens to compile for a 32-bit build might end up with a bunch of warnings when compiled for a 64-bit build, or vice versa. The only sane way to have an OS like Zephyr that aspires to be highly portable without making the code (both the OS itself and existing apps) is to enforce consistent types across architectures and bus sizes. While I fully understand that this might put some burden on legacy code users, the alternative is to move that burden onto the Zephyr code and all the other users instead. I don't see this alternative being beneficial on the long run. So, to keep benefits on the majority side, and because compiler defaults aren't helping the cause, I'm not in favor of this PR.

[mnkp]

Let me explain my case in a bit more detail. We have built an SDK in form of a bare metal application that we use internally and provide also to third parties so they can build their products using our solution. It runs using standard gcc build process. We have another version of the SDK which is build as a Zephyr application. It provides some extra functionality like firmware over the air update (using mcuboot as a bootloader) and shell subsystem. With time we plan to move completely to Zephyr but this is not the case yet. This is a valid use case. Since #16645 was merged I had to manually patch Zephyr code base every time when making a release, I wouldn't like to do it any more. No need to say, our bare metal SDK version is using fully valid C syntax and builds clean. Without patching Zephyr the same code generates tons of warnings.

The only sane way to have an OS like Zephyr that aspires to be highly portable without making the code (both the OS itself and existing apps) is to enforce consistent types across architectures and bus sizes.

This is true, however not applicable to this discussion since stdint types are not allowed in Zephyr code base. Zephyr defines its own set of fixed size types u32_t, u16_t and alike. Had Zephyr been using stdint types then indeed the solution proposed in this PR would not be viable.

At the moment stdint types are fully reserved for the applications that are build on top of Zephyr and there is no need to artificially restrict those. Not everyone writes code that aims to be portable across architectures.

Current approach also puts much higher burden on anyone who has existing legacy code and would like to run it as a Zephyr application. It can impact acceptance of Zephyr as a go to solution.

I'm not asking to revert #16645, that's good work, I'm happy we have it. All I'm asking for is to give users an option to build their applications using stdint types as defined by the compiler. The default behavior remains as is.

[npitre]

On Sun, 20 Oct 2019, Piotr Mienkowski wrote: No need to say, our bare metal SDK version is using fully valid C syntax and builds clean. Without patching Zephyr the same code generates tons of warnings.

Do you intend to support 64-bit MCUs eventually? If so you'll get tons of warnings if you don't patch your own code already.

> The only sane way to have an OS like Zephyr that aspires to be > highly portable without making the code (both the OS itself and > existing apps) is to enforce consistent types across architectures > and bus sizes. This is true, however not applicable to this discussion since stdint types are not allowed in Zephyr code base.

Why not? Definitions provided by this include file are environment dependent. Zephyr creates its own environment and provides a corresponding stdint.h for you to use.

At the moment stdint types are fully reserved for the applications that are build on top of Zephyr and there is no need to artificially restrict those. Not everyone writes code that aims to be portable across architectures.

But you must be aware that with your patch and the config option turned off, it is some parts of Zephyr itself that will emit warnings when built and fail the build or CI since it has been adjusted to those types already.

Current approach also puts much higher burden on anyone who has existing legacy code and would like to run it as a Zephyr application. It can impact acceptance of Zephyr as a go to solution.

Sorry, but I don't really buy this argument without concrete examples. The burden isn't _that_ high given that adjusting Zephyr itself to those streamlined types was trivial. Since this is legacy code you're talking about, it is certainly 32-bit based. Most of what you need to do in that case is to replace longs with ints in your code or something equally trivial, and the compiled binary will stay the same.

I'm not asking to revert #16645, that's good work, I'm happy we have it. All I'm asking for is to give users an option to build their applications using stdint types as defined by the compiler. The default behavior remains as is.

Although I think it would be better for you to modify your code, I'm not going to veto your patch. However I'd prefer if you made a few changes: * Reverse the meaning of CONFIG_ZEPHYR_STDINT with sometthing like CONFIG_IGNORE_ZEPHYR_STDINT to make the exception explicit. * Add a note about this option in the kconfig help text warning people to problems that come with default definitions provided by the compiler and that they should avoid this option if they can. Some of the original commit log content may be used for this. Might also be worth noting that such Zephyr configuration is not validated by the CI loop, etc.

[mnkp]

By merging #25679 we moved to using stdint types natively in the Zephyr tree. This PR is no longer applicable. Closing.