Re: Making structs with variable-sized arrays unsized?

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

On Fri, Sep 18, 2020 at 12:33:56PM -0700, Linus Torvalds wrote:
> Luc,
>  we've been making kernel structures use flexible arrays as a
> cleanliness thing, but it turns out that it doesn't find bugs that it
> _should_ find.
> 
> We have that nice "struct_size()" macro to determine the size of the
> flexible structure given the number of elements, which uses "offsetof
> + n*members". But sadly standard C still allows the (nonsensical)
> 'sizeof()' to be used - and I merged another fix for that just today.
> 
> Ok, so that's a C standard problem, but it's something that sparse
> *could* warn about.

Yes, sure.
I think that sparse treats flexible arrays exactly as if zero-sized,
without the notion of 'incomplete type' and without check that it is
the last member, so without any warnings.
This, I think, explains the results in your tests here under.

I'll look to add some warnings for array declaration and sizeof()
(explicit or implicit).

> Comments? Appended is a kind of test-case for odd situations that
> sparse happily and silently generates nonsensical code for (just
> tested with test-linearize).

Thanks, these tests make a lot of sense.
It should be noted, though, that test-linearize gives exactly the
same result as GCC & clang (sparse IR 100% matches x86 & ARM64 here).

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 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?

>     // 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

What could be optimized here?

-- Luc