On Wed, Jan 11, 2023 at 11:23:07AM +0100, Morten Brørup wrote: > > From: Bruce Richardson [mailto:bruce.richard...@intel.com] > > Sent: Wednesday, 11 January 2023 11.10 > > > > One additional point that just became clear to me when I started > > thinking > > about upping our DPDK C-standard-baseline. We need to be careful what > > we > > are considering when we up our C baseline. We can mandate a specific > > compiler minimum and C version for compiling up DPDK itself, but I > > think we > > should not mandate that for the end applications. > > Why not? > > And do you consider this backwards compatibility a build time or run time > requirement? > > > > > That means that our header files, such as atomics, should not require > > C99 > > or C11 even if the build of DPDK itself does. More specifically, even > > if we > > bump DPDK minimum to C11, we should still allow apps to build using > > older > > compiler settings. > > > > Therefore, we probably need to maintain non-C11 atomics code paths in > > headers beyond the point at which DPDK itself uses C11 as a code > > baseline. > > Am I misunderstanding your suggestion here: Code can be C11, but all APIs and > header files must be C89? > > Wouldn't that also prevent DPDK inline functions from being C11? > Yes, it would.
Now, perhaps we don't need to ensure that our headers have strict C89 compatibility, but I think we need to be very careful about mandating that end-user apps use particular c standard settings when compiling their own code.
