[RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Bruce Richardson]

Traditionally, DPDK has never specified a minimum C standard used either
in DPDK builds or for applications using DPDK. Following discussion
on-list about C standards, this RFC attempts to start the process of
codifying what our standards expectations are. No code changes are made
by this RFC, instead only the build parameters are changed to explicitly
specify:

* C99 standard is used to build DPDK itself. This is supported by all
  supported compiler versions of GCC and Clang.
* The headers are checked for compatibility with gcc89 standard, which
  was the default standard used by the oldest supported version of GCC.
  DPDK headers do not build with the official C89 standard, and, to the
  best of my knowledge, have never done so.

Bruce Richardson (1):
  build: increase minimum C standard for DPDK builds

 buildtools/chkincs/meson.build | 1 +
 meson.build                    | 1 +
 2 files changed, 2 insertions(+)

--
2.37.2

[RFC PATCH 1/1] build: increase minimum C standard for DPDK builds

[Bruce Richardson]

Set the default C language standard to be used for DPDK builds to C99.
This requires no actual code changes to build successfully.

To ensure compatibility is kept for external apps using DPDK headers, we
explicitly set the build parameters for the chkincs binary to the old
minimum standard of "gnu89". [NOTE: DPDK code does not compile and has
previously not compiled for pure c89 standard, so that stricter
requirement need not be checked.] By adding this additional check, we
can separately manage C standards used internally in DPDK builds and
that required in the build flags for external apps using DPDK.

Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
---
 buildtools/chkincs/meson.build | 1 +
 meson.build                    | 1 +
 2 files changed, 2 insertions(+)

diff --git a/buildtools/chkincs/meson.build b/buildtools/chkincs/meson.build
index 378c2f19ef..322ac775ce 100644
--- a/buildtools/chkincs/meson.build
+++ b/buildtools/chkincs/meson.build
@@ -30,6 +30,7 @@ executable('chkincs', sources,
         c_args: cflags,
         include_directories: includes,
         dependencies: deps,
+        override_options: 'c_std=gnu89',
         install: false)
 
 # run tests for c++ builds also
diff --git a/meson.build b/meson.build
index f91d652bc5..9a2963cc16 100644
--- a/meson.build
+++ b/meson.build
@@ -9,6 +9,7 @@ project('DPDK', 'C',
         license: 'BSD',
         default_options: [
             'buildtype=release',
+            'c_std=c99',
             'default_library=static',
             'warning_level=2',
         ],
-- 
2.37.2

RE: [RFC PATCH 1/1] build: increase minimum C standard for DPDK builds

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 12 January 2023 12.36
> 
> Set the default C language standard to be used for DPDK builds to C99.
> This requires no actual code changes to build successfully.

Great!

> 
> To ensure compatibility is kept for external apps using DPDK headers,
> we
> explicitly set the build parameters for the chkincs binary to the old
> minimum standard of "gnu89". [NOTE: DPDK code does not compile and has
> previously not compiled for pure c89 standard, so that stricter
> requirement need not be checked.] By adding this additional check, we
> can separately manage C standards used internally in DPDK builds and
> that required in the build flags for external apps using DPDK.

It seems I have to accept this techboard decision for now. ;-)

> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---

Acked-by: Morten Brørup <mb@smartsharesystems.com>

Re: [RFC PATCH 1/1] build: increase minimum C standard for DPDK builds

[Bruce Richardson]

On Thu, Jan 12, 2023 at 01:42:48PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Thursday, 12 January 2023 12.36
> > 
> > Set the default C language standard to be used for DPDK builds to C99.
> > This requires no actual code changes to build successfully.
> 
> Great!
> 
> > 
> > To ensure compatibility is kept for external apps using DPDK headers,
> > we
> > explicitly set the build parameters for the chkincs binary to the old
> > minimum standard of "gnu89". [NOTE: DPDK code does not compile and has
> > previously not compiled for pure c89 standard, so that stricter
> > requirement need not be checked.] By adding this additional check, we
> > can separately manage C standards used internally in DPDK builds and
> > that required in the build flags for external apps using DPDK.
> 
> It seems I have to accept this techboard decision for now. ;-)
> 
There is no techboard decision here - certainly not yet. There is plenty of
discussion still to be had. However, for now this RFC is being very
conservative - perhaps overly so.

/Bruce

RE: [RFC PATCH 1/1] build: increase minimum C standard for DPDK builds

[Morten Brørup]

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Thursday, 12 January 2023 13.47
> 
> On Thu, Jan 12, 2023 at 01:42:48PM +0100, Morten Brørup wrote:
> > > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > > Sent: Thursday, 12 January 2023 12.36
> > >
> > > Set the default C language standard to be used for DPDK builds to
> C99.
> > > This requires no actual code changes to build successfully.
> >
> > Great!
> >
> > >
> > > To ensure compatibility is kept for external apps using DPDK
> headers,
> > > we
> > > explicitly set the build parameters for the chkincs binary to the
> old
> > > minimum standard of "gnu89". [NOTE: DPDK code does not compile and
> has
> > > previously not compiled for pure c89 standard, so that stricter
> > > requirement need not be checked.] By adding this additional check,
> we
> > > can separately manage C standards used internally in DPDK builds
> and
> > > that required in the build flags for external apps using DPDK.
> >
> > It seems I have to accept this techboard decision for now. ;-)
> >
> There is no techboard decision here - certainly not yet. There is
> plenty of
> discussion still to be had. However, for now this RFC is being very
> conservative - perhaps overly so.

Yeah, perhaps I was phrasing that somewhat emotionally loaded. :-)

I didn't mean to cause confusion on the mailing list. Thanks for clarifying, Bruce.

Re: [RFC PATCH 1/1] build: increase minimum C standard for DPDK builds

[Tyler Retzlaff]

On Thu, Jan 12, 2023 at 11:35:56AM +0000, Bruce Richardson wrote:
> Set the default C language standard to be used for DPDK builds to C99.
> This requires no actual code changes to build successfully.
> 
> To ensure compatibility is kept for external apps using DPDK headers, we
> explicitly set the build parameters for the chkincs binary to the old
> minimum standard of "gnu89". [NOTE: DPDK code does not compile and has
> previously not compiled for pure c89 standard, so that stricter
> requirement need not be checked.] By adding this additional check, we
> can separately manage C standards used internally in DPDK builds and
> that required in the build flags for external apps using DPDK.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
>  buildtools/chkincs/meson.build | 1 +
>  meson.build                    | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/buildtools/chkincs/meson.build b/buildtools/chkincs/meson.build
> index 378c2f19ef..322ac775ce 100644
> --- a/buildtools/chkincs/meson.build
> +++ b/buildtools/chkincs/meson.build
> @@ -30,6 +30,7 @@ executable('chkincs', sources,
>          c_args: cflags,
>          include_directories: includes,
>          dependencies: deps,
> +        override_options: 'c_std=gnu89',
>          install: false)
>  
>  # run tests for c++ builds also
> diff --git a/meson.build b/meson.build
> index f91d652bc5..9a2963cc16 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -9,6 +9,7 @@ project('DPDK', 'C',
>          license: 'BSD',
>          default_options: [
>              'buildtype=release',
> +            'c_std=c99',
>              'default_library=static',
>              'warning_level=2',
>          ],

subject to the atomics abstraction proposal where a meson option is
provided enable_stdatomics=true we'll want to be able to upgrade to
-std=c11 / c_std=c11 (as a minimum).

is there a meson mechanism that will let us evaluate that condition and
specify the higher required standard version in default_options  or is it
a matter of some post project() or is this just done by adding
-std=c11 using add_project_arguments() after project()?

second, i think you will run into a build break with this change on some
platform / compiler combinations. somewhere we are using strerror_r where
the required posix versions are not specified in the translation unit
worked around by using c_std=gnu99 or by adding appropriate undef GNUC
etc.. in the place where strerror_r is used. (just something i noticed
when testing a similar change during prototyping i think ubuntu
22.04?)

going one step further i'd just ask that the default options be
"portable" i.e. they work with ! gcc and ! clang to help me with future
work. though i know that contradicts with my advice in the previous
paragraph, maybe we can set c_std=xxx subject to toolchain/platform?

Acked-by: Tyler Retzlaff <roretzla@linux.microsoft.com>

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Ben Magistro]

[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]

Since this topic keeps coming up in other threads I'll chime in with my
$0.01 here.  We've been using CentOS 7 for awhile (and working on migrating
off) but have had to leverage devtoolset/llvmtoolset for various reasons.
I remember a discussion of installing a different compiler coming up but
don't remember which thread that was in/what the outcome was.  While I'd
like to just brush over C7 and say there is a compatible compiler available
so just make the change I also realize that making that change could be
quite disruptive to existing code bases.

However, the 22.11 LTS will be EOL in Nov 2024.  CentOS 7 is EOL Jun 2024.
For the 23.x series and going forward I don't think starting with a C11
requirement is an unreasonable ask.

On Thu, Jan 12, 2023 at 6:36 AM Bruce Richardson <bruce.richardson@intel.com>
wrote:

> Traditionally, DPDK has never specified a minimum C standard used either
> in DPDK builds or for applications using DPDK. Following discussion
> on-list about C standards, this RFC attempts to start the process of
> codifying what our standards expectations are. No code changes are made
> by this RFC, instead only the build parameters are changed to explicitly
> specify:
>
> * C99 standard is used to build DPDK itself. This is supported by all
>   supported compiler versions of GCC and Clang.
> * The headers are checked for compatibility with gcc89 standard, which
>   was the default standard used by the oldest supported version of GCC.
>   DPDK headers do not build with the official C89 standard, and, to the
>   best of my knowledge, have never done so.
>
> Bruce Richardson (1):
>   build: increase minimum C standard for DPDK builds
>
>  buildtools/chkincs/meson.build | 1 +
>  meson.build                    | 1 +
>  2 files changed, 2 insertions(+)
>
> --
> 2.37.2
>
>

[-- Attachment #2: Type: text/html, Size: 2246 bytes --]

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Bruce Richardson]

On Fri, Feb 03, 2023 at 09:09:14AM -0500, Ben Magistro wrote:
>    Since this topic keeps coming up in other threads I'll chime in with my
>    $0.01 here.  We've been using CentOS 7 for awhile (and working on
>    migrating off) but have had to leverage devtoolset/llvmtoolset for
>    various reasons.  I remember a discussion of installing a different
>    compiler coming up but don't remember which thread that was in/what the
>    outcome was.  While I'd like to just brush over C7 and say there is a
>    compatible compiler available so just make the change I also realize
>    that making that change could be quite disruptive to existing code
>    bases.
>    However, the 22.11 LTS will be EOL in Nov 2024.  CentOS 7 is EOL Jun
>    2024.  For the 23.x series and going forward I don't think starting
>    with a C11 requirement is an unreasonable ask.
> 
Thanks for that input. If we drop support for Centos/RHEL 7, I think we
should be ok to pass -std=c11 for the build of DPDK.

Have you any thoughts on the second part of the c11 move - where our
headers require c11 support and therefore may require that the end user
builds their own code using -std=c11? This latter part is the bit that
concerns me a little, as I feel it may be problematic for some with older
codebases.

/Bruce

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Ben Magistro]

[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]

In our case we have other libraries that we are using that have required us
to specify a minimum c++ version (14/17 most recently for one) so it
doesn't feel like a big ask/issue to us (provided things don't start
conflicting...hah; not anticipating any issue).  Our software is also used
internally so we have a fair bit of control over how fast we can adopt
changes.

This got me wondering what some other projects in the DPDK ecosystem are
saying/doing around language standards/gcc versions.  So some quick
checking of the projects I am aware of/looked at/using...
* trex: cannot find an obvious minimum gcc requirement
* tldk: we are running our own public folk with several fixes, need to find
time to solve the build sys change aspect to continue providing patches
upstream; I know I have hit some places where it was easier to say the new
minimum DPDK version is x at which point you just adopt the minimum
requirements of DPDK
* ovs: looks to be comfortable with an older gcc still
* seastar: seems to be the most aggressive with adopting language
standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+
* ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and is the
same on the main README file

I do understand the concern, but if no one is voicing an opinion/objection
does that mean they agree with/will not be affected by the change....

1) https://docs.seastar.io/master/md_compatibility.html
2) https://github.com/ansyun/dpdk-ans/releases

Cheers

On Fri, Feb 3, 2023 at 10:09 AM Bruce Richardson <bruce.richardson@intel.com>
wrote:

> On Fri, Feb 03, 2023 at 09:09:14AM -0500, Ben Magistro wrote:
> >    Since this topic keeps coming up in other threads I'll chime in with
> my
> >    $0.01 here.  We've been using CentOS 7 for awhile (and working on
> >    migrating off) but have had to leverage devtoolset/llvmtoolset for
> >    various reasons.  I remember a discussion of installing a different
> >    compiler coming up but don't remember which thread that was in/what
> the
> >    outcome was.  While I'd like to just brush over C7 and say there is a
> >    compatible compiler available so just make the change I also realize
> >    that making that change could be quite disruptive to existing code
> >    bases.
> >    However, the 22.11 LTS will be EOL in Nov 2024.  CentOS 7 is EOL Jun
> >    2024.  For the 23.x series and going forward I don't think starting
> >    with a C11 requirement is an unreasonable ask.
> >
> Thanks for that input. If we drop support for Centos/RHEL 7, I think we
> should be ok to pass -std=c11 for the build of DPDK.
>
> Have you any thoughts on the second part of the c11 move - where our
> headers require c11 support and therefore may require that the end user
> builds their own code using -std=c11? This latter part is the bit that
> concerns me a little, as I feel it may be problematic for some with older
> codebases.
>
> /Bruce
>

[-- Attachment #2: Type: text/html, Size: 3673 bytes --]

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Bruce Richardson]

On Fri, Feb 03, 2023 at 11:45:04AM -0500, Ben Magistro wrote:
>    In our case we have other libraries that we are using that have
>    required us to specify a minimum c++ version (14/17 most recently for
>    one) so it doesn't feel like a big ask/issue to us (provided things
>    don't start conflicting...hah; not anticipating any issue).  Our
>    software is also used internally so we have a fair bit of control over
>    how fast we can adopt changes.
>    This got me wondering what some other projects in the DPDK ecosystem
>    are saying/doing around language standards/gcc versions.  So some quick
>    checking of the projects I am aware of/looked at/using...
>    * trex: cannot find an obvious minimum gcc requirement
>    * tldk: we are running our own public folk with several fixes, need to
>    find time to solve the build sys change aspect to continue providing
>    patches upstream; I know I have hit some places where it was easier to
>    say the new minimum DPDK version is x at which point you just adopt the
>    minimum requirements of DPDK
>    * ovs: looks to be comfortable with an older gcc still
>    * seastar: seems to be the most aggressive with adopting language
>    standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+
>    * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and is
>    the same on the main README file
>    I do understand the concern, but if no one is voicing an
>    opinion/objection does that mean they agree with/will not be affected
>    by the change....
>    1) [1]https://docs.seastar.io/master/md_compatibility.html
>    2) [2]https://github.com/ansyun/dpdk-ans/releases
>    Cheers
> 
Thanks for the info.
I also notice that since gcc 5, the default language version used - if none
is explicitly specified - is gnu11 (or higher for later versions). Clang
seems to do something similar, but not sure at what point it started
defaulting to a standard >=c11.

/Bruce

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Ben Magistro]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

Adding Tyler

Sort of following along on the RFC: introduce atomics [1] it seems like the
decision to use 99 vs 11 here could make an impact on the approach taken in
that thread.

1) http://mails.dpdk.org/archives/dev/2023-February/262042.html

On Fri, Feb 3, 2023 at 1:00 PM Bruce Richardson <bruce.richardson@intel.com>
wrote:

> On Fri, Feb 03, 2023 at 11:45:04AM -0500, Ben Magistro wrote:
> >    In our case we have other libraries that we are using that have
> >    required us to specify a minimum c++ version (14/17 most recently for
> >    one) so it doesn't feel like a big ask/issue to us (provided things
> >    don't start conflicting...hah; not anticipating any issue).  Our
> >    software is also used internally so we have a fair bit of control over
> >    how fast we can adopt changes.
> >    This got me wondering what some other projects in the DPDK ecosystem
> >    are saying/doing around language standards/gcc versions.  So some
> quick
> >    checking of the projects I am aware of/looked at/using...
> >    * trex: cannot find an obvious minimum gcc requirement
> >    * tldk: we are running our own public folk with several fixes, need to
> >    find time to solve the build sys change aspect to continue providing
> >    patches upstream; I know I have hit some places where it was easier to
> >    say the new minimum DPDK version is x at which point you just adopt
> the
> >    minimum requirements of DPDK
> >    * ovs: looks to be comfortable with an older gcc still
> >    * seastar: seems to be the most aggressive with adopting language
> >    standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+
> >    * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and
> is
> >    the same on the main README file
> >    I do understand the concern, but if no one is voicing an
> >    opinion/objection does that mean they agree with/will not be affected
> >    by the change....
> >    1) [1]https://docs.seastar.io/master/md_compatibility.html
> >    2) [2]https://github.com/ansyun/dpdk-ans/releases
> >    Cheers
> >
> Thanks for the info.
> I also notice that since gcc 5, the default language version used - if none
> is explicitly specified - is gnu11 (or higher for later versions). Clang
> seems to do something similar, but not sure at what point it started
> defaulting to a standard >=c11.
>
> /Bruce
>

[-- Attachment #2: Type: text/html, Size: 3226 bytes --]

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Tyler Retzlaff]

On Fri, Feb 10, 2023 at 09:52:06AM -0500, Ben Magistro wrote:
> Adding Tyler
> 
> Sort of following along on the RFC: introduce atomics [1] it seems like the
> decision to use 99 vs 11 here could make an impact on the approach taken in
> that thread.

hey Ben thanks for keeping an eye across threads on the topic. the
atomics thread is fairly long but somewhere in it i did provide a
rationale for why we can't just go straight to using C11 even if we
declared that dpdk on supports compilers >= C11.

i wish we could it would certainly make my life way easier if i could
just -std=c11 and cut & paste my way to completion. the reason why we
can't (aside from not requiring C11 compiler as a minimum) is that there
is potential issue with abi compatibility for existing applications
using non-atomic types currently passed to ABI suddenly requiring
standard atomic types. this is because _Atomic type and type are not
guaranteed to have the same size, alignment, representation etc..

anyway, i welcome us establishing c99 as a minimum for all
toolchain/platform combinations.

> 
> 1) http://mails.dpdk.org/archives/dev/2023-February/262042.html
> 
> On Fri, Feb 3, 2023 at 1:00 PM Bruce Richardson <bruce.richardson@intel.com>
> wrote:
> 
> > On Fri, Feb 03, 2023 at 11:45:04AM -0500, Ben Magistro wrote:
> > >    In our case we have other libraries that we are using that have
> > >    required us to specify a minimum c++ version (14/17 most recently for
> > >    one) so it doesn't feel like a big ask/issue to us (provided things
> > >    don't start conflicting...hah; not anticipating any issue).  Our
> > >    software is also used internally so we have a fair bit of control over
> > >    how fast we can adopt changes.
> > >    This got me wondering what some other projects in the DPDK ecosystem
> > >    are saying/doing around language standards/gcc versions.  So some
> > quick
> > >    checking of the projects I am aware of/looked at/using...
> > >    * trex: cannot find an obvious minimum gcc requirement
> > >    * tldk: we are running our own public folk with several fixes, need to
> > >    find time to solve the build sys change aspect to continue providing
> > >    patches upstream; I know I have hit some places where it was easier to
> > >    say the new minimum DPDK version is x at which point you just adopt
> > the
> > >    minimum requirements of DPDK
> > >    * ovs: looks to be comfortable with an older gcc still
> > >    * seastar: seems to be the most aggressive with adopting language
> > >    standards/compilers I've seen [1] and are asking for gcc 9+ and cpp17+
> > >    * ans: based on release 19.02 (2019), they are on gcc >= 5.4 [2] and
> > is
> > >    the same on the main README file
> > >    I do understand the concern, but if no one is voicing an
> > >    opinion/objection does that mean they agree with/will not be affected
> > >    by the change....
> > >    1) [1]https://docs.seastar.io/master/md_compatibility.html
> > >    2) [2]https://github.com/ansyun/dpdk-ans/releases
> > >    Cheers
> > >
> > Thanks for the info.
> > I also notice that since gcc 5, the default language version used - if none
> > is explicitly specified - is gnu11 (or higher for later versions). Clang
> > seems to do something similar, but not sure at what point it started
> > defaulting to a standard >=c11.
> >
> > /Bruce
> >

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Tyler Retzlaff]

On Thu, Jan 12, 2023 at 11:35:55AM +0000, Bruce Richardson wrote:
> Traditionally, DPDK has never specified a minimum C standard used either
> in DPDK builds or for applications using DPDK. Following discussion
> on-list about C standards, this RFC attempts to start the process of
> codifying what our standards expectations are. No code changes are made
> by this RFC, instead only the build parameters are changed to explicitly
> specify:
> 
> * C99 standard is used to build DPDK itself. This is supported by all
>   supported compiler versions of GCC and Clang.
> * The headers are checked for compatibility with gcc89 standard, which
>   was the default standard used by the oldest supported version of GCC.
>   DPDK headers do not build with the official C89 standard, and, to the
>   best of my knowledge, have never done so.

subject to the technical board meeting 2023/02/22 in relation to atomics
and adoption of C11 starting in 23.11 does anything stop us from
conditionally enabling/defaulting -std=C11 for all platforms immediately
except for RHEL/CentOS 7?

so long as we don't actually start using C11 features we should be able
to do this? or would we be worried that C11 feature use would creep in?

just curious.

> 
> Bruce Richardson (1):
>   build: increase minimum C standard for DPDK builds
> 
>  buildtools/chkincs/meson.build | 1 +
>  meson.build                    | 1 +
>  2 files changed, 2 insertions(+)
> 
> --
> 2.37.2

Re: [RFC PATCH 0/1] Specify C-standard requirement for DPDK builds

[Bruce Richardson]

On Wed, Feb 22, 2023 at 10:53:44AM -0800, Tyler Retzlaff wrote:
> On Thu, Jan 12, 2023 at 11:35:55AM +0000, Bruce Richardson wrote:
> > Traditionally, DPDK has never specified a minimum C standard used either
> > in DPDK builds or for applications using DPDK. Following discussion
> > on-list about C standards, this RFC attempts to start the process of
> > codifying what our standards expectations are. No code changes are made
> > by this RFC, instead only the build parameters are changed to explicitly
> > specify:
> > 
> > * C99 standard is used to build DPDK itself. This is supported by all
> >   supported compiler versions of GCC and Clang.
> > * The headers are checked for compatibility with gcc89 standard, which
> >   was the default standard used by the oldest supported version of GCC.
> >   DPDK headers do not build with the official C89 standard, and, to the
> >   best of my knowledge, have never done so.
> 
> subject to the technical board meeting 2023/02/22 in relation to atomics
> and adoption of C11 starting in 23.11 does anything stop us from
> conditionally enabling/defaulting -std=C11 for all platforms immediately
> except for RHEL/CentOS 7?
> 
> so long as we don't actually start using C11 features we should be able
> to do this? or would we be worried that C11 feature use would creep in?
> 
> just curious.
> 
Actually, if we don't do anything, the versions of gcc (and clang AFAIK)
already default to C11 or later from GCC 5 onwards. If we were to specify a
version, I think it would have to be gnu11 as we may still be using some
GCC extensions. However, feel free to do up a patch for c11 if it works.
The change to the header checks probably don't need to be included, only a
change to the default options in the top-level meson.build file.

Incidentally, even though it is missing support for the c11 atomics, gcc
4.8.5 on RHEL 7 does have the -std=c11 flag that can be used, so adding
that shouldn't break anything.

/Bruce