Re: [PATCH] RFC: use C11 alignas instead of GCC attribute aligned

[Tyler Retzlaff <roretzla@linux.microsoft.com>]

On Tue, Jan 30, 2024 at 05:59:25PM +0000, Bruce Richardson wrote:
> On Tue, Jan 30, 2024 at 09:39:28AM -0800, Tyler Retzlaff wrote:
> > On Tue, Jan 30, 2024 at 09:08:21AM +0100, Mattias Rönnblom wrote:
> <snip>
> > > 
> > > Sorry if I've missed some discussion on the list, but the current
> > > pattern of putting __rte_aligned(X) at the end doesn't work with MSVC,
> > > or why are we doing this? C11 purism doesn't seem like much of a
> > > driving force.
> > 
> > __rte_aligned(X) at the end doesn't work with MSVC __declspec(align(n))
> > 
> > > 
> > > If one defined a macro as __declspec(align(X)) on MSVC and
> > > __attribute__(__aligned__(X)) on other compilers, could it do the work
> > > of both the above RTE_ALIGNAS() and RTE_ALIGN_TYPE()?
> > > 
> > > <a> struct <b> { int a; } <c>;
> > 
> > yes for struct/union. but only when placed at location you mark as <b>
> > when compiling both C and C++ for all toolchains.
> > 
> I can see this restriction on placement potentially causing problems. Maybe
> we should consider defining macros with the "struct" keywork included. For
> example, (using gcc attributes here):

i had considered this but it might be overkill.
* it will be picked up by windows/msvc ci build.
* once established as the common visual pattern in the source it will be
  cut n' pasted at low rate of error.

> 
> #define rte_aligned_struct(n) struct __attribute((aligned(n)))
> 
> rte_aligned_struct my_struct {
> 	int a;
> }
> 
> Probably that's taking things a bit far away from standard C, but it may
> cut down on placement errors.
> 
> /Bruce