> On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
>
> On 2023-08-03 13:34, Qing Zhao wrote:
>> One thing I need to point out first is, currently, even for regular fixed
>> size array in the structure,
>> We have this same issue, for example:
>> #define LENGTH 10
>> struct fix {
>> size_t foo;
>> int array[LENGTH];
>> };
>> …
>> int main ()
>> {
>> struct fix *p;
>> p = alloc_buf_more ();
>> expect(__builtin_object_size(p->array, 1), LENGTH * sizeof(int));
>> expect(__builtin_object_size(p->array, 0), -1);
>> }
>> Currently, for __builtin_object_size(p->array, 0), GCC return UNKNOWN for
>> it.
>> This is not a special issue for flexible array member.
>
> That's fine for fixed arrays at the end of a struct because the "whole
> object" size could be anything; `p` could be pointing to the beginning of an
> array for all we know. If however `array` is strictly a flex array, i.e.:
>
> ```
> struct A
> {
> size_t foo;
> int array[];
> };
> ```
>
> then there's no way in valid C to have an array of `struct fix`,
Yes!! this is exactly the place that makes difference between structures with
fixed arrays and the ones with flexible arrays.
With such difference, I guess that using the type of the structure with
flexible array member for p->array to get the size of the whole object p point
to might be reasonable?
> so `q` must be pointing to a single element. So you could deduce:
>
> 1. the minimum size of the whole object that q points to.
You mean that the TYPE will determine the minimum size of the whole object?
(Does this include the size of the flexible array member, or only the other
part of the structure except the flexible array member?)
>
> and
>
> 2. if you're able to determine the size of the flex array (through
> __element_count__(foo) for example), you could even determine the maximum
> size of the whole object.
>
> For (2) though, you'd break applications that overallocate and then expect to
> be able to use that overallocation despite the space not being reflected in
> the __element_count__. I think it's a bug in the application and I can't see
> a way for an application to be able to do this in a valid way so I'm inclined
> towards breaking it.
Currently, we allow the situation when the allocation size for the whole object
is larger than the value reflected in the “counted_by” attribute (the old name
is __element_count__). But don’t allow the other way around (i.e, when the
allocation size for the whole object is smaller than the value reflected in the
“counted_by” attribute.
>
> Of course, the fact that gcc allows flex arrays to be in the middle of
> structs breaks the base assumption but that's something we need to get rid of
> anyway since there's no way for valid C programs to use that safely.
Since GCC14, we started to deprecate this extension (allow flex array to be in
the middle of structs).
https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html
Thanks.
Qing
>
> Thanks,
> Sid
