diff options
author | Alejandro Colomar <alx@kernel.org> | 2022-10-28 01:49:55 +0200 |
---|---|---|
committer | Andrew Clayton <a.clayton@nginx.com> | 2024-03-13 16:29:24 +0000 |
commit | b65e49c5d6b4c9395d84257b71d380f10bb5823f (patch) | |
tree | 463af98b75c696ce0b71183dae467c61dcad6cac /auto/cc | |
parent | 7472a2ca2403541f4bc292fe74af90c808388281 (diff) | |
download | unit-b65e49c5d6b4c9395d84257b71d380f10bb5823f.tar.gz unit-b65e49c5d6b4c9395d84257b71d380f10bb5823f.tar.bz2 |
Build with -std=gnu11 (C11 with GNU extensions)
Currently Unit doesn't specify any specific C standard for compiling and
will thus be compiled under whatever the compiler happens to default to.
Current releases of GCC and Clang (13.x & 17.x respectively at the time
of writing) default to gnu17 (C17 + GNU extensions).
Our oldest still-supported system is RHEL/CentOS 7, that comes with GCC
4.8.5 which defaults to gnu90.
Up until now this hasn't really been an issue and we have been able to
use some C99 features that are implemented as GNU extensions in older
compilers, e.g
- designated initializers
- flexible array members
- trailing comma in enum declaration (compiles with -std=c89, warns
with -std=c89 -pedantic)
- snprintf(3)
- long long (well we test for it but don't actually use it)
- bool / stdbool.h
- variadic macros
However there are a couple of C99 features that aren't GNU extensions
that would be handy to be able to use, i.e
- The ability to declare variables inside for () loops, e.g
for (int i = 0; ...; ...)
- C99 inline functions (not to be confused with what's available with
-std=gnu89).
However, if we are going to switch up to C99, then perhaps we should
just leap frog to C11 instead (the Linux Kernel did in fact make the
switch from gnu89 to gnu11 in March '22). C17 is perhaps still a little
new and is really just C11 + errata.
GCC 4.8 as in RHEL 7 has *some* support for C11, so while we can make
full use of C99, we couldn't yet make full use of C11, However RHEL 7 is
EOL on June 30th 2024, after which we will no longer have that
restriction and in the meantime we can restrict ourselves to the
supported set of features (or implement fallbacks where appropriate).
It can only be a benefit that we would be compiling Unit consistently
under the same language standard.
This will also help give the impression that Unit is a modern C code
base.
It is also worth noting the following regarding GCC
"A version with corrections integrated was prepared in 2017 and published
in 2018 as ISO/IEC 9899:2018; it is known as C17 and is supported with
-std=c17 or -std=iso9899:2017; the corrections are also applied with -
std=c11, and the only difference between the options is the value of
STDC_VERSION."
Suggested-by: Andrew Clayton <a.clayton@nginx.com>
Acked-by: Andrew Clayton <a.clayton@nginx.com>
[ Andrew wrote the commit message ]
Signed-off-by: Alejandro Colomar <alx@kernel.org>
Link: <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8c07082a810fbb9db303a2b66b66b8d7e588b53>
Link: <https://www.ibm.com/blog/announcement/ibm-is-announcing-red-hat-enterprise-linux-7-is-going-end-of-support-on-30-june-2024/>
Link: <https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Standards.html#C-Language>
Cc: Dan Callahan <d.callahan@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
Diffstat (limited to 'auto/cc')
-rw-r--r-- | auto/cc/test | 5 |
1 files changed, 3 insertions, 2 deletions
diff --git a/auto/cc/test b/auto/cc/test index 4d6d5a43..34e4379e 100644 --- a/auto/cc/test +++ b/auto/cc/test @@ -67,8 +67,7 @@ case $NXT_CC_NAME in NXT_CFLAGS="$NXT_CFLAGS -fno-strict-overflow" - # c99/gnu99 conflict with Solaris XOPEN. - #NXT_CFLAGS="$NXT_CFLAGS -std=gnu99" + NXT_CFLAGS="$NXT_CFLAGS -std=gnu11" NXT_CFLAGS="$NXT_CFLAGS -O" NXT_CFLAGS="$NXT_CFLAGS -Wall -Wextra" @@ -110,6 +109,8 @@ case $NXT_CC_NAME in NXT_CFLAGS="$NXT_CFLAGS -fno-strict-overflow" + NXT_CFLAGS="$NXT_CFLAGS -std=gnu11" + NXT_CFLAGS="$NXT_CFLAGS -O" NXT_CFLAGS="$NXT_CFLAGS -Wall -Wextra" |