Re: RFC abstracting atomics

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jan 11, 2023 at 11:23:07AM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@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.