On 2023-08-04 11:27, Qing Zhao wrote:
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?
Yes, that's what I'm thinking.
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?)
Only the constant sized part of the structure.
Actually for minimum size we'd also need a guarantee that `alloc_buf_more`
returns a valid allocated object.
Why? Please explain a little bit here.
So `alloc_buf_more` could return NULL, a valid pointer or an invalid
pointer. So, we could end up returning a non-zero minimum size for an
invalid or NULL pointer, which is incorrect, we don't know that.
We won't need the object validity guarantee for (2) beyond, e.g.
guarding against a new NULL pointer dereference because it's a *maximum*
estimate; an invalid or NULL pointer would have 0 size. So for such
cases, __bos(q, 0) could return
sizeof(*q) + (q ? q->foo:0)
and __bos(q->array, 0) could be
sizeof(*q) + q->foo - offsetof(q, array)
There's no need to guard against a dereference in the second case
because the q->array dereference already assumes that q is valid.
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.
Right, that's going to be the "break". For underallocation __bos will
only end up overestimating the space available, which is not ideal, but
won't end up breaking compatibility.
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
Yes, that's what I'm banking on.
Thanks,
Sid
