On 2026-09-21 07:48, Gustavo A. R. Silva wrote:
I think you're confusing type 1 with type 2; type 1 is the *maximum*
subobject size, not the minimum. The whole object and subobject size
distinction is only material if there are members after inner, which
is technically "supported" by the complier as an extension, but is a
terrible idea for members with FAM.
Here are the different possibilities for &p->inner:
1. If the allocation via __builtin_malloc is visible: same result for
types 0, 1, 2 and 3, i.e. allocated size - offsetof (struct outer, inner)
When the allocation is visible and the FAM is annotated with counted_by,
we use
the information provided by counted_by. See commit 6f17933548fc ("Use the
.ACCESS_WITH_SIZE in builtin object size.")
Yes, the counted_by would basically override allocated size information,
since the .ACCESS_WITH_SIZE gets emitted after the allocation.
BTW, I recently filed this related issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127234
OK, so is this the core problem you're trying to solve? It's different
from pr126975, which AFAICT is NOTABUG since it confuses type-1 with type-3.
2. If the __builtin_malloc is not visible and there's no counted_by
annotation:
- type 0 and type 1: cannot determine size, since FAM could be any
arbitrary size. So, -1
- type 2 and type 3: sizeof (&p->inner), since that's the minimum
estimate.
3. if the __builtin_malloc is not visible and FAM has __counted_by__
annotation: same result for all types: sizeof (&p->inner) + p->count
I would, however, expect the use of counted_by to change it. For
example, if it were this:
struct flex {
size_t count;
char fam[] __attribute__((counted_by(count)));
};
...
struct outer *p = __builtin_malloc (sizeof (*p) + 48); /* 64-byte
object */
p->inner.count = 48;
I would expect the results to be:
ok: __builtin_object_size (&p->inner, 1) == 8 /* compile-time
size */
ok: __builtin_dynamic_object_size (&p->inner, 1) == 56 /* run-time
size */
I agree with counted_by changing things here. This is actually something
that Jakub mentioned in a comment to v1 of this patch:
"What we certainly can change is the behavior when
-fstrict-flex-arrays unless it already behaves the expected way,
and perhaps also when the flex array has counted_by attribute."
See: https://lore.kernel.org/linux-hardening/aogVH8UtICMP1Ihv@tucnak/#t
BTW, I have a patch ready for PR127234 (the missed counted_by bug) where
I implemented some helper functions to get the size of the object based
on the information provided by counted_by. I could use those in this PR. :)
Yes, I agree this would be interesting to fix. I'm not sure if it needs
to be under -fstrict-flex-arrays=3 though, since the size of the FAM
itself will always be dictated by the counted_by; this will just be an
extension of that behaviour.
Thanks,
Sid
