On Sat, Nov 08, 2025 at 10:59:59PM +0530, Ankit Khushwaha wrote:
> On Tue, Oct 28, 2025 at 05:23:12PM +0000, Simon Horman wrote:
> > On Mon, Oct 27, 2025 at 10:38:56AM +0530, Ankit Khushwaha wrote:
> > > Some network selftests defined variable-sized types defined at the end of
> > > struct causing -Wgnu-variable-sized-type-not-at-end warning.
> > >
> > > warning:
> > > timestamping.c:285:18: warning: field 'cm' with variable sized type
> > > 'struct cmsghdr' not at the end of a struct or class is a GNU
> > > extension [-Wgnu-variable-sized-type-not-at-end]
> > > 285 | struct cmsghdr cm;
> > > | ^
> > >
> > > ipsec.c:835:5: warning: field 'u' with variable sized type 'union
> > > (unnamed union at ipsec.c:831:3)' not at the end of a struct or class
> > > is a GNU extension [-Wgnu-variable-sized-type-not-at-end]
> > > 835 | } u;
> > > | ^
> > >
> > > This patch move these field at the end of struct to fix these warnings.
> > >
> > > Signed-off-by: Ankit Khushwaha <[email protected]>
> >
> > Hi Ankit,
> >
> > I don't believe this change is correct.
> >
> > I think that the intention of the code is the char arrays (buf and control)
> > provide the buffer space for the variable-length trailing field
> > of the preceding structure. Where we basically have a header followed
> > by data. But your patch would place the before the header.
> >
> Hi Simon,
> So if buf and control providing the buffer space, then i think it is
> better to suppress `-Wgnu-variable-sized-type-not-at-end` warning
> within this block of code.
>
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored "-Wgnu-variable-sized-type-not-at-end"
I'm unsure of the attitude towards using #pragma like this in kernel code,
but certainly it would be a new one for me.
>
> struct {
> union {
> struct xfrm_algo alg;
> struct xfrm_algo_aead aead;
> struct xfrm_algo_auth auth;
> } u;
> char buf[XFRM_ALGO_KEY_BUF_SIZE];
> } alg = {};
>
> #pragma GCC diagnostic pop
>
> I think this would be fine.
In my view, the most promising approach I am aware of is using
TRAILING_OVERLAP(), as illustrated in [1]. However, that
approach was recently rejected, so I guess that means
it doesn't have much promise after all.
[1] https://lore.kernel.org/netdev/aPdx4iPK4-KIhjFq@kspp/
