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

[Morten Brørup]

> From: Andre Muezerie [mailto:andremue at 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 at 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?

> +
> +/**
> + * 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.

> + *
> + * @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.
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?

Should the use of these workaround macros be disallowed in new code?
I.e. should checkpatches check for them?