Re: ToT glibc build problem with ToT GCC

[Carlos O'Donell <carlos at redhat dot com>]

On 8/30/19 7:02 AM, Szabolcs Nagy wrote:
> On 29/08/2019 20:17, Carlos O'Donell wrote:
>> Is there a viable solution for a static allocation of a structure
>> that ends in a VLA?
> 
> flexible array member should be possible to allocate with a union:
> 
> static union
> {
>   struct { int nbytes; char bytes[N]; } xxx;
>   struct { int nbytes; char bytes[]; } replace;
> } u;
> 
> then u.replace has N extra bytes allocated (and initialized to 0).
> 
> (i think you can use u.xxx and u.replace interchangeably with
> a lax interpretation of the "common initial sequence" rule
> http://port70.net/~nsz/c/c11/n1570.html#6.5.2.3p6 )
> 
> if you don't want to repeat the struct type definition then
> 
> static union
> {
>   struct foo replace;
>   char xxx[sizeof(struct foo) + N];
> } u;

Right, this is the solution I was thinking about using.

> should work (but the tail bytes are not initialized with this
> ordering, the other ordering initializes u.xxx but you have
> to rely on type punning when accessing u.replace which is safe
> with gcc).
> 
> these should not trigger out-of-bounds warnings.

Does it avoid the interior zero-length array problem Martin was
saying was "iffy" from the compiler perspective?

I realize now that Martin kept 'struct charseq replace[2]' in his
example, which did mean that there was an "interior" zero-length
array after the first array element. We don't need to use 'replace[2]'
if we have a union and the total union size is large enough.

-- 
Cheers,
Carlos.