Re: Making structs with variable-sized arrays unsized?

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Fri, Sep 18, 2020 at 01:49:46PM -0700, Linus Torvalds wrote:
> On Fri, Sep 18, 2020 at 1:41 PM Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> >
> > I also have 2 questions here under.
> >
> > >     struct bad {
> > >         unsigned long long a;
> > >         char b[];
> > >     };
> > ...
> > >     // The layout is odd
> > >     // The code does "info->align_size = 0" for unsized arrays, but it
> > > still works?
> > >     int odd(struct bad *a)
> > >     {
> > >         return __alignof__(*a);
> > >     }
> >
> > This returns 8. What's odd here?
> 
> The fact that it works correctly.
> 
> > The 0 align_size is only for the member 'b' and shouldn't have any
> > effect on the alignment of the whole struct. What am I missing?
> 
> I wrote that code by looking at the sparse source, and _expected_ it
> to return the wrong value.
> 
> Because the sparse code does
> 
>         /*
>          * Unsized arrays cause us to not align the resulting
>          * structure size
>          */
>         if (base_size < 0) {
>                 info->align_size = 0;
>                 base_size = 0;
>         }
> 
> so I expected that when base_size < 0, we'd drop the _previous_
> alignment we saved.
> 
> But what I suspect goes on is that base_size is actually 0, not < 0.
> But I didn't verify.

OK, I see. I'll check this.
 
> > >     // Arrays of flexible-array structures are pretty nonsensical
> > >     // Plus we don't even optimize the constant return. Sad.
> > >     int not_nice(struct bad p[2])
> > >     {
> > >         return (void *)(p+1) - (void *)p;
> > >     }
> >
> > I don't understand what you mean by 'optimize the constant return'.
> > test-linearize returns the only possible sensical answer (if the size
> > of the structure is accepted to be 8):
> >         not_nice:
> >         .L2:
> >                 <entry-point>
> >                 ret.32      $8
> 
> That's not what I see. I see
> 
>   not_nice:
>   .L2:
>         <entry-point>
>         add.64      %r3 <- %arg1, $8
>         sub.64      %r5 <- %r3, %arg1
>         trunc.32    %r6 <- (64) %r5
>         ret.32      %r6
> 
> which is rather different and not exactly optimal.
> 
> That wasn't what I _intended_ to look for, obviously. I expected the
> code you quote.
> 
> I wonder why it works for you but not me.

My fault, sorry. By error, I didn't run these tests on the head but in
one of my branches that coincidentally had some patches doing some
reassociation which then triggers the optimization.

-- Luc