summaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorAlejandro Colomar <alx@kernel.org>2022-10-28 01:49:55 +0200
committerAndrew Clayton <a.clayton@nginx.com>2024-03-13 16:29:24 +0000
commitb65e49c5d6b4c9395d84257b71d380f10bb5823f (patch)
tree463af98b75c696ce0b71183dae467c61dcad6cac
parent7472a2ca2403541f4bc292fe74af90c808388281 (diff)
downloadunit-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>
-rw-r--r--auto/cc/test5
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"