[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

["qinzhao at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896

--- Comment #39 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #38)
> struct foo {
>    int n;
>    char (*buf)[.n];
> };
> 
> void store(struct foo* p, int a, int b) { (*p->buf)[a] = b; }
> 
> int main()
> {
>   struct foo p = { 7, &(char[7]){ 0 } };
>   store(&p, 7, 1);
> }
> 
> With UBSan, this should give this error:
> ex.c:8:52: runtime error: index 7 out of bounds for type 'char [*]'
yes, this worked. and with -fdump-tree-gimple, I can see the IR representation
for this test case. thanks.

> In the parser for '.n' I create a component ref with a placeholder
> expression inside it.  But then later when creating a component
> ref for p->buf  I replace all placeholder expressions in the
> *type* of p->buf  with *p. So the type of p->buf has a
> <placeholder>.n  as size expression somewwere and this 
> becomes p.n.

the above explanation is very clean. thanks.
but the thing that confused me is: is the *type* of p->buf Pointer or Array? 

From the source code, it's a pointer, right? if so, why embed the array size to
it?

> Yes, potentially. But a FAM has special semantics and the
> code for this detects this based on the missing size (I think).

Yes, that's true. currently, we determine a FAM as the following (c-decl.cc):

/* Determine whether TYPE is a ISO C99 flexible array memeber type "[]".  */
static bool
flexible_array_member_type_p (const_tree type)
{
  if (TREE_CODE (type) == ARRAY_TYPE
      && TYPE_SIZE (type) == NULL_TREE
      && TYPE_DOMAIN (type) != NULL_TREE
      && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) == NULL_TREE)
    return true;

  return false;
}

So, if we want to change the syntax of FAM to include size info, and embedded
this size info to the TYPE, then we need to adjust all the places in FE or in
Middle end that depend on the current FAM IR. Yes, potentially much bigger
changes. 

therefore, directly extending the FAM syntax to include the size info might
involve bigger change than attribute approach. 

We can implement attribute first, and then later do the syntax extension. 
that might be safer. 

> I tried the other thing first, because it seemed simpler and
> could potentially serve as a basis for the FAM case.  But I am
> not so sure anymore, because of the issue mentioned below.
Okay, I see now.

> For the FAM case we should probably attach the attribute
> to the member and read it directly in the object size pass,
> similar how this is now done for the access attributes for
> parameters.

Yes, implementation of attribute should be simpler and safer. 
I will try to come up with a patch on this attribute. 

> 
> I also thought that passing the information via the type
> would be better, but I am not sure how to do this at the
> moment.

Yes, passing the Size info through the type will be better, we can implement
this syntax extension later if the attribute works very well, and we can
promote it to a real language standard at that time.