Re: [wish] Flexible array members in unions

[Qing Zhao <qing.zhao@oracle.com>]

> On May 18, 2023, at 12:25 PM, Martin Uecker via Gcc <gcc@gcc.gnu.org> wrote:
> 
> 
> 
>> On Thu, May 11, 2023 at 11:14 PM Kees Cook via Gcc <gcc@gcc.gnu.org> wrote:
>>> 
>>> On Thu, May 11, 2023 at 08:53:52PM +0000, Joseph Myers wrote:
>>>> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
>>>> 
>>>>> On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
>>>>>> On 5/11/23 18:07, Alejandro Colomar wrote:
>>>>>> [...]
>>>>>>> Would you allow flexible array members in unions?  Is there any
>>>>>>> strong reason to disallow them?
>>>>> 
>>>>> Yes please!! And alone in a struct, too.
>>>>> 
>>>>> AFAICT, there is no mechanical/architectural reason to disallow them
>>>>> (especially since they _can_ be constructed with some fancy tricks,
>>>>> and they behave as expected.) My understanding is that it's disallowed
>>>>> due to an overly strict reading of the very terse language that created
>>>>> flexible arrays in C99.
>>>> 
>>>> Standard C has no such thing as a zero-size object or type, which would
>>>> lead to problems with a struct or union that only contains a flexible
>>>> array member there.
> 
> (I think it is fundamentally not too problematic to have zero-size
> objects, although it would take some work to specify the semantics
> exactly.)
> 
> But my preference would be to make structs / unions with FAM an
> incomplete type which would then restrict their use (for the cases
> now supported we would need backwards compatible exceptions).
> We could then allow such a struct / union as the last member
> of another struct / union which would make this an incomplete
> type too.

Yes, I like this approach. 
And we can make them GCC extensions first,  promote to C standard later.

My proposed patch sets (originally targeted on GCC13, now might need to target on GCC14) will
make one part of the above a GCC extension:
    Allowing the struct with FAM as the last member of another struct. (See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832)

https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614794.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614793.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614790.html

I’d like these changes going into GCC first to improve this area.

> 
> We then would need a special macro (based on a builtin) instead
> of sizeof to get the size, but this would be safer anyway.
> 
> In principle, an even better solution would be to allow dynamic
> arrays because then it has a dynamic bound where the type with
> the bound could propagate to some user. Bounds checking would
> work as expected and more cases.
> 
> struct foo {
>  int len;
>  char buf[.len];
> };
> 
> But this takes a bit more work to get right.
> 
>>> 
>>> Ah-ha, okay. That root cause makes sense now.
>> 
>> Hmm. but then the workaround
>> 
>> struct X {
>>  int n;
>>  union u {
>>      char at_least_size_one;
>>      int iarr[];
>>      short sarr[];
>>  };
>> };
>> 
>> doesn't work either.  We could make that a GNU extension without
>> adverse effects?
> 
> I think we could allow this even without the "at_least_size_one"
> without a problem when allowing the use of such unions only as
> a last member of some structure. Allowing it elsewhere seems
> questionable anyway.

Yes,  Such an union can be treated as an flexible array member 
(just multiple flexible arrays sharing the same storage).  Therefore it’s reasonable
To only allow it as the last field of a structure. 

thanks.

Qing.

> 
>> Richard.
>> 
>>> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
>>> question is: what's needed to support the idea of a zero-sized object?
> 
> Probably a lot of convincing that it actually does not cause problems,
> and is useful. Also a lot of work in making sure the standard is revised
> everywhere where it is necessary. I think zero sized objects and
> especially arrays are very useful also to avoid special code for corner
> cases in numerical algorithms. But I think here some restrictions on
> the use of the FAM will do.
> 
> 
> Martin