RFC: C11 (or C17) requirement

[carlescufi]

With the C language evolving, there are a few features in ISO/IEC 9899:2011 (aka C11) that would be useful to Zephyr developers. Given that compiler support for it seems to be already widespread, I'd like to start the conversation to discuss whether switching to it as a requirement to build Zephyr is something we would like to consider.
We could instead require C17, given that it is functionally equivalent to C11 but with some issues addressed.

Please use this issue to describe both features from C11 that you'd like to use and objections or showstoppers that you can foresee if we moved forward with the transition.

[nordic-krch]

It seems that logger would benefit greatly from _Generic feature added in C11. It allows to evaluate at compile time type of the parameter allowing to detect at compile time:

• potential strings (char *) which would allow to do internal string duplication without need of explicit log_strdup call which was always a problem
• floats for which double space needs to be allocated.
• logging 64 bit values

[pabigot]

Detecting multi-word arguments should already be handled in cbprintf, but log_strdup() is a problem. Though I'm not clear how _Generic could help with a varargs API like logging.

Browsing the C11 additions:

• Using standard thread APIs could be useful. People clearly want that in C++ for Zephyr, and the C semantics should be compatible.

A consideration is that MISRA is not yet past C99.

[carlescufi]

@tejlmand could you comment on the full list of toolchains to check support for?
My assumption here is that the list is currently restricted to:

• GCC: Yes (4.9)
• clang: Yes (3.0)
• Metaware: Yes (version?)
• armclang: ?
• esp32 IDF: Yes (based on GCC 8.4 or later)
• Cadence: No
• IAR: ?

[tejlmand]

My assumption here is that the list is currently restricted to:

Looks precise enough to me.
Unsure how this would impact custom toolchains, @daor-oti comments ?

For the versions, I think:
gcc

• 9.x.x, Zephyr SDK 0.12 is using 10, but gnuarmemb is GCC 9 based.

clang

• 10.0.0 as that is what has recently been introduced.

[pabigot]

The current ESP32 (xtensa) toolchain is:

xtensa-esp32-elf-cc (crosstool-NG esp-2020r3) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.

[manoj153]

My assumption here is that the list is currently restricted to:

Looks precise enough to me.
Unsure how this would impact custom toolchains, @daor-oti comments ?

For the versions, I think:
gcc

• 9.x.x, Zephyr SDK 0.12 is using 10, but gnuarmemb is GCC 9 based.

clang

• 10.0.0 as that is what has recently been introduced.

issuing command :

./arm-zephyr-eabi-gcc -v

returns :

gcc version 10.2.0 (crosstool-NG 1.24.0.212_d7da3a9) 

Development environment:

1. zephyr-sdk-0.12.0
2. STM32H7xx

from reading from devdocs seems GCC v10 supports C17, I can write my app code successfully with C17?

[daor-oti]

@tejlmand Thanks for asking. Our toolchain uses clang 9.0.0 as frontend and as such it supports both C11 and C17. We actually set -std=c11 for clang today and have done for a long time. For our custom backend, is a little more difficult to determine whether there will be some corner C11/C17 unsupported areas, but I suspect there will be very few, if any.
So, for our toolchain point of view, I see no immediate problem with Zephyr requiring either C11 or C17.

[pabigot]

A propósito, somebody should verify or update the recommended toolchain for Vega, which is currently GCC 7.1.1. @MaureenHelm

I'm unable to make it work with west with the following commands:

export ZEPHYR_TOOLCHAIN_VARIANT=cross-compile
export CROSS_COMPILE=/usr/local/openisa/bin/riscv32-unknown-elf-

which does work with cmake/ninja directly.

[evgeniy-paltsev]

Latest ARC GNU toolchain is GCC 10.2.0 based (both toolchain from Zephyr SDK 0.12 and standalone prebuilt one)
Latest ARC MWDT toolchain is LLVM 10.0.1 based.

[pabigot]

Here are version numbers that can be used to determine C standard versions at compile-time with code like:

#if ((__STDC__VERSION__ - 0) >= 201112L)
/* at least C11 */
#endif

Version	__STDC__VERSION__
C90	not defined
C95 (C90 + AMD 1)	199409L
C99	199901L
C11	201112L
C17	201710L
C20	202000L

[galak]

@nashif can you add details on cadence compiler here.

[nashif]

cadence compiler does not support C11

[dleach02]

cadence compiler does not support C11

What is the version it does support?

[carlescufi]

@jhol you recently pushed for changes to improve GCC 4.x support in #84119. Could you please state the impact of this proposal to you and your employer so we can take it into account?

[nandojve]

Could C23, formally ISO/IEC 9899:2024 be considered?

[carlescufi]

Could C23, formally ISO/IEC 9899:2024 be considered?

I discussed this briefly with @nashif. I think that might be a bit too recent to require it at this point.

[jhol]

We are stuck with GCC 4.1.2. I have a collection of patches to get the features that we need working with it - many of which I have upstreamed. If the C standard is increased it obviously has a bigger impact if this is applied to core constructions such as the device tree, sysinit or device macros versus more peripheral features.

[carlescufi]

We are stuck with GCC 4.1.2.

@jhol For the foreseeable future? We have been extremely cautious when it comes to updating our minimum required C standard version, but this issue is now close to 5 years old, and C11 itself is close to 15 years old.

[jhol]

I think zephyr just needs to go ahead with whatever is best for the project. I don't see the need to aggressively break support for C99, but I also don't think the project should expend effort trying to support ancient language standards.

We are stuck with GCC 4.1.2 because of a tool chain for a vendor architecture port for which we ought to get the source code, but that we won't get.

Sadly not atypical inthe embedded space

[marc-hb]

We are stuck with GCC 4.1.2.

The typical solution is: stick to a stable and older Zephyr branch too. Keeping old codebases bug-free and secure is very expensive - but it's less of a maintenance nightmare than trying to piece old stuff and new stuff together.

After a while, this will mean bearing the maintenance cost of that stable Zephyr branch yourself. And of course you will get zero new feature. Up to the corresponding vendor whether this is preferable to supporting more recent toolchain(s). C is always touted as "low-level and portable", so how hard could it be to support LLVM? ;-) For sure clang has always been bending over backwards to be as "CLI API" compatible as possible with gcc.

[carlescufi]

I think zephyr just needs to go ahead with whatever is best for the project. I don't see the need to aggressively break support for C99, but I also don't think the project should expend effort trying to support ancient language standards.

Thanks @jhol. If you are interested this will be discussed tomorrow in the TSC meeting.

[carlescufi]

FYI @RobinKastberg @LoveKarlsson @bjorniuppsala I assume this won't be an issue for IAR?

[LoveKarlsson]

FYI @RobinKastberg @LoveKarlsson @bjorniuppsala I assume this won't be an issue for IAR?

I don't think so

[cfriedt]

Generics FTW \o/

[JordanYates]

Could C23, formally ISO/IEC 9899:2024 be considered?

I discussed this briefly with @nashif. I think that might be a bit too recent to require it at this point.

It's worth not forgetting about though. There seems to be quite a number of features in C23 that would be useful.

• Specify the storage type of enums (Big fan of this one)
• Builtin overflow safe integer arithmatic, ckd_add, ckd_mul, etc.
• #embed (In combination with west binary blobs)
• Bit manipulation (Replace a bunch of toolchain specific macros, popcount etc)
• Binary number formatting for printf/scanf
• Specifying numbers in a clearer fashion, e.g. 0b10101010, 299'792'458
• Surely __VA_OPT__ could be abused to introduce fun new macrobatics :)

[Thalley]

Just a note, MISRA C:2012 - Amendment 2: Updates for ISO/IEC 9899:2011 core functionality, ISBN 978-906400-25-5 (PDF), February 2020.

This document amends MISRA C:2012 as required to introduce support for ISO/IEC 9899:2011. Subsequent amendments will be used to introduce specific guidance for the features introduced by ISO/IEC 9899:2011

Today MISRA C:2023 and C:2025 also exists with support for C11 and C17/18: https://www.perforce.com/resources/qac/misra-c-cpp

[donatieng]

We internally already require C11 to be used in all of our Zephyr work, mostly for static assertions and anonymous structures, so we'd definitely welcome this change! C23 has a lot of interesting features too but we've not tried it out in a Zephyr project yet.

[marc-hb]

We internally already require C11 to be used in all of our Zephyr work, mostly for static assertions and anonymous structures, so we'd definitely welcome this change!

Can you elaborate? AFAIK it's already possible to use C11 today without making changes to Zephyr, is it not? This issue is about bumping the minimum version required.

[kartben]

We internally already require C11 to be used in all of our Zephyr work, mostly for static assertions and anonymous structures, so we'd definitely welcome this change!

Can you elaborate? AFAIK it's already possible to use C11 today without making changes to Zephyr, is it not? This issue is about bumping the minimum version required.

I think they're just saying that they're having their downstream Zephyr work setup with C11 as a minimum so as to make sure they can leverage the new features, and are happy with it :)

[donatieng]

Apologies, my first comment was not the clearest.
We have a SDK (https://github.com/blecon/blecon-device-sdk) that our users can integrate in their Zephyr application to use our technology.
Using our SDK requires them to use C11 (or higher) with their application as well, so for us it's better if this becomes the default in Zephyr so that we can drop this additional requirement/difference.

[carlescufi]

Could C23, formally ISO/IEC 9899:2024 be considered?

I discussed this briefly with @nashif. I think that might be a bit too recent to require it at this point.

It's worth not forgetting about though. There seems to be quite a number of features in C23 that would be useful.

Definitely. One thing I will do is open a similar RFC for C23 once we've established C11 as the base C standard for Zephyr, so that we can track it closely. Hopefully it won't take nearly as long to switch to it.

[teburd]

Skip 11, go straight to the fixed up C17, particularly w.r.t. atomics

[cfriedt]

100% on atomics

[cfriedt]

I think we will definitely need a system to track all of the changes related to the uplift in minimum version. Maybe a new label area: c17?

There are quite a few weird hacks all over the place to account for different language revisions. Do any toolchains or static analysis tools exist to scan an entire codebase and come up with recommended changes?

@fabiobaltieri - can AI help here ?? 😅

[RobinKastberg]

From IAR:

• As toolchain vendors, we don't mind as long as it is <= C17.
• As Zephyr contributors: If lifting, we prefer C17 to C11.
• As Zephyr contributors: We worry there are other code hygiene issues that time could be better spent on (e.g. VLAs or removing GNUisms).

[carlescufi]

• As Zephyr contributors: We worry there are other code hygiene issues that time could be better spent on (e.g. VLAs or removing GNUisms).

Would you mind creating an enhancement issue for those please?