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`, 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.
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.
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.
Thanks,
Sid
