Re: [PATCH v15 1/3] eal: add diagnostics macros to make code portable

[Andre Muezerie <andremue@linux.microsoft.com>]

On Tue, Jan 21, 2025 at 03:41:09PM +0100, Morten Brørup wrote:
> > From: Andre Muezerie [mailto:andremue@linux.microsoft.com]
> > Sent: Tuesday, 21 January 2025 15.28
> > 
> > On Tue, Jan 21, 2025 at 10:53:14AM +0100, Morten Brørup wrote:
> > > > From: Andre Muezerie [mailto:andremue@linux.microsoft.com]
> > > > Sent: Saturday, 18 January 2025 22.55
> > > >
> > > > It was a common pattern to have "GCC diagnostic ignored" pragmas
> > > > sprinkled over the code and only activate these pragmas for certain
> > > > compilers (gcc and clang). Clang supports GCC's pragma for
> > > > compatibility with existing source code, so #pragma GCC diagnostic
> > > > and #pragma clang diagnostic are synonyms for Clang
> > > > (https://clang.llvm.org/docs/UsersManual.html).
> > > >
> > > > Now that effort is being made to make the code compatible with MSVC
> > > > these expressions would become more complex. It makes sense to hide
> > > > this complexity behind macros. This makes maintenance easier as
> > these
> > > > macros are defined in a single place. As a plus the code becomes
> > > > more readable as well.
> > > >
> > > > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> > > > ---
> > > >  lib/eal/include/rte_common.h | 46
> > ++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 46 insertions(+)
> > > >
> > > > diff --git a/lib/eal/include/rte_common.h
> > > > b/lib/eal/include/rte_common.h
> > > > index 40592f71b1..4b87a0a352 100644
> > > > --- a/lib/eal/include/rte_common.h
> > > > +++ b/lib/eal/include/rte_common.h
> > > > @@ -156,6 +156,52 @@ typedef uint16_t unaligned_uint16_t;
> > > >  #define RTE_DEPRECATED(x)
> > > >  #endif
> > > >
> > > > +/**
> > > > + * Macros to cause the compiler to remember the state of the
> > diagnostics as of
> > > > + * each push, and restore to that point at each pop.
> > > > + */
> > > > +#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC)
> > > > +#define __rte_diagnostic_push _Pragma("GCC diagnostic push")
> > > > +#define __rte_diagnostic_pop  _Pragma("GCC diagnostic pop")
> > > > +#else
> > > > +#define __rte_diagnostic_push
> > > > +#define __rte_diagnostic_pop
> > > > +#endif
> > > > +
> > > > +/**
> > > > + * Macro to disable compiler warnings about removing a type
> > > > + * qualifier from the target type.
> > > > + */
> > > > +#if !defined(__INTEL_COMPILER) && !defined(RTE_TOOLCHAIN_MSVC)
> > > > +#define __rte_diagnostic_ignored_wcast_qual \
> > > > +		_Pragma("GCC diagnostic ignored \"-Wcast-qual\"")
> > > > +#else
> > > > +#define __rte_diagnostic_ignored_wcast_qual
> > > > +#endif
> > > > +
> > > > +/**
> > > > + * Workaround to discard qualifiers (such as const, volatile,
> > restrict) from a pointer,
> > > > + * without the compiler emitting a warning.
> > > > + */
> > > > +#define RTE_PTR_UNQUAL(X) ((void *)(uintptr_t)(X))
> > >
> > > It seems the C23 typeof_unqual and the built-in pre-C23
> > __typeof_unqual__ couldn't be used.
> > > Was it a generic issue, or only when operating on (the return value
> > of) functions?
> > 
> > I experimented with C23 typeof_unqual. It indeed works on gcc, clang
> > and MSVC, but there are some details:
> > 
> > a) With gcc the project needs to be compiled with -std=c2x. Many other
> > warnings show up, unrelated to the scope of this patchset. Some look
> > suspicious and should be looked at. An error also showed up, for which
> > I sent out a small patch.
> > 
> > b) When using typeof_unqual and passing "-Wcast-qual" to the compiler,
> > a warning about the qualifier being dropped is emitted. The project
> > currently uses "-Wcast-qual". Perhaps it shouldn't?
> 
> The compiler is our friend; when more warnings enabled, the code quality requirements are higher.

I agree 100% with this.

> Although this statement may not be universally true, I think it is for "-Wcast-qual".
> 
> > 
> > Due to (a) I decided to not use typeof_unqual for now, but it would be
> > trivial to change the macro to do so in the future.
> 
> How about __typeof_unqual__ (with double underscores prefix and postfix)?
> It seems to be available in both GCC [1] and MSVC [2] without requiring C23.
> 
> [1]: https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
> [2]: https://learn.microsoft.com/en-us/cpp/c-language/typeof-unqual-c?view=msvc-170

__typeof_unqual__ (with double underscores prefix and postfix) requires gcc-14. On gcc-13 this keyword is not defined.
It works exactly like C23 typeof_unqual: When -Wcast-qual is passed to the compiler a warning is emitted when discarding a qualifier from the pointer target type, which is treated as error in the DPDK build. Without -Wcast-qual it compiles cleanly.

> 
> > 
> > >
> > > > +
> > > > +/**
> > > > + * Workaround to discard qualifiers (such as const, volatile,
> > restrict) from a pointer
> > > > + * and cast it to a specific type, without the compiler emitting a
> > warning.
> > >
> > > Propose new description with emphasis on casting rather than
> > discarding qualifiers:
> > >
> > > Workaround to cast a pointer to a specific type,
> > > without the compiler emitting a warning about discarding qualifiers.
> > >
> > 
> > I'll update this.
> > 
> > > > + *
> > > > + * @warning
> > > > + * Although this macro can be abused for casting a pointer to
> > point to a different type,
> > > > + * alignment may be incorrect when casting to point to a larger
> > type. E.g.:
> > >
> > > This macro is now meant for abuse, so propose softening the warning:
> > >
> > > When casting a pointer to point to a larger type,
> > > the resulting pointer may be misaligned,
> > > which causes undefined behavior.
> > 
> > I'll update this.
> > 
> > > E.g.:
> > >
> > > > + *   struct s {
> > > > + *       uint16_t a;
> > > > + *       uint8_t  b;
> > > > + *       uint8_t  c;
> > > > + *       uint8_t  d;
> > > > + *   } v;
> > > > + *   uint16_t * p = RTE_CAST_PTR(uint16_t *, &v.c); // "p" is not
> > 16 bit aligned!
> > > > + */
> > > > +#define RTE_CAST_PTR(type, ptr) ((type)(uintptr_t)(ptr))
> > >
> > > I am somewhat concerned about these macros...
> > >
> > > There's a good reason why MSVC doesn't allow casting to discard
> > qualifiers or changing the type like this.
> > >
> > > If in doubt, read this:
> > > https://www.trust-in-soft.com/resources/blogs/2020-04-06-gcc-always-
> > assumes-aligned-pointer-accesses
> > >
> > > We need these workarounds because DPDK currently contains code with
> > formally "undefined behavior".
> > > And instead of fixing the root causes, we choose the pragmatic
> > solution and introduce workarounds to allow it.
> > >
> > > Would it be possible for the RTE_CAST_PTR macro to check if the
> > casted-to pointer changes from a smaller type to a larger type, and
> > warn/fail if it does?
> > 
> > I'll think about it.
> > >
> > > Should the use of these workaround macros be disallowed in new code?
> > > I.e. should checkpatches check for them?
> > 
> > We can certainly add a check to checkpatches.