> From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> Sent: Friday, 11 August 2023 17.55
>
> On Fri, Aug 11, 2023 at 11:42:12AM +0200, Morten Brørup wrote:
> > > From: Tyler Retzlaff [mailto:roret...@linux.microsoft.com]
> > > Sent: Friday, 11 August 2023 03.32
> > >
> > > Provide API for atomic operations in the rte namespace that may
> > > optionally be configured to use C11 atomics with meson
> > > option enable_stdatomics=true
> > >
> > > Signed-off-by: Tyler Retzlaff <roret...@linux.microsoft.com>
> > > ---
[...]
> >
> > Move the (changed) C11 memory order type definition here:
> >
> > /* The memory order is an enumerated type in C11. */
> > #define memory_order rte_memory_order
No objections to your typedef in v2.
[...]
> > > +#ifdef __ATOMIC_SEQ_CST
> > > +_Static_assert(rte_memory_order_seq_cst == __ATOMIC_SEQ_CST,
> > > + "rte_memory_order_seq_cst == __ATOMIC_SEQ_CST");
> > > +#endif
> >
> > Excellent idea adding these _Static_asserts!
> >
> > Have you tested (with the toolchain you are targeting with this
> _Static_assert) that e.g. __ATOMIC_RELAXED is actually #defined, so the
> preprocessor can see it? (I guess that being a built-it, it might not be a
> #define, it might be a magic value known by the compiler only.)
>
> * llvm and gcc both expose it as a built-in #define for test builds i
> have run. worst case the assert is lost if it isn't.
I only wanted to check that we didn't always hit the "worst case" where the
static_assert is lost, so thank you for the confirmation regarding GCC/clang.
> * since i have to handle non-{clang,gcc} too i still guard with ifdef
Agree.
> * i do need to switch to using assert.h static_assert macro to
> inter-operate with c++ in v2
OK. I reviewed that in v2 too.
-Morten
