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

["muecker at gwdg dot de" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #28 from Martin Uecker <muecker at gwdg dot de> ---
Am Mittwoch, dem 08.03.2023 um 16:56 +0000 schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> 
> --- Comment #23 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #13)
> > 
> > VLAs and VM types exist since C99 and were made optional in C11.
> > The minimal change we adopted to make support for VM types 
> > (but not VLAs) mandatory again was:
> > 
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf
> 
> So, this will be official in C23? i.e, VM types will be mandatory, but VLA will
> be optional (and later might be deprecated?)

Yes, this is in C23. But no, the plan is *not* to deprecate VLAs.

I really hope we can make VLAs mandatory at some point as well
and I will push very much in this direction.

This reason is that VLAs are very good properties:

- automatic memory management
- run-time bounds (which can be used for checking)

The problems with VLA are in my opinion caused by poor
implementation (e.g. no stack probing etc) and bad
code generation (Linus was not happy about this) and
not because anything is fundamentally bad about them
from the point of language semantics.


They are now often replaced by fixed size buffers on
the stack, which I think is a step backwards form the
point of security because the information about the
precise run-time bound is lost.


> > 
> > I think using PLACEHOLDER_EXPR that are insert into the size
> > expression and then replaced later by the struct being accessed, 
> > e.g.
> > 
> > struct foo {
> >  int len;
> >  char buf[PLACEHOLDER_EXPR.len]
> > };
> > 
> > and then later when we have
> > 
> > struct foo x;
> > 
> > x->buf
> > 
> > we would replace in the size of the type for x->buf the placeholder
> > with x itself.
> 
> I see. Yes, this will resolve the implementation difficulty for filling the
> size of the FAM field when the size is the previous declared field in the same
> structure. 
> 
> 
> > Yes, this was what I wanted to do...  My main use case is not flexible
> > array members but VM types in struct:
> > 
> > struct foo {
> >   int len;
> >   char (*buf)[.len];
> > };
> > 
> > 
> > This has less issues because the size of the struct then does not depend
> > on the length.
> 
> a little confused here:
> what's the definition of VM type? it's size will not depend on the ".len" ?

VM = variably modified.  In C it is a type which is derived from
a VLA which is not necessarily itself a VLA, e.g. a pointer to
a VLA. But a VLA is also a VM type.

Martin


>