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

--- Comment #20 from Martin Uecker <muecker at gwdg dot de> ---
Am Montag, dem 06.03.2023 um 19:15 +0000 schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> 
> --- Comment #18 from Bill Wendling <isanbard at gmail dot com> ---
> (In reply to Martin Uecker from comment #17)
> > Am Freitag, dem 03.03.2023 um 23:18 +0000 schrieb isanbard at gmail dot com:
> > 

...
> 
> > But even we make it resolve the name, which we
> > have to do for all proposals, it is something  different.
> > 
> > If offsetof it would resolve the count of a different
> > struct of the same *type* (here a non-existent one at 
> > address zero). Here we need a self reference to the
> > same *object*.
> > 
> If we make it an attribute, we have more control over what the arguments mean,
> what they refer to, etc.
> 
> For the record, I'm not opposed to the idea of using the designated 
> initializer
> syntax. I just think it's good to explore other ideas before settling on
> extending C (which is a bit heavy-handed).

I agree. An attribute is simple and extending C will take
more care (and work).

The reason I think we should also extend C (together with
WG14) is because this would allow writing code where the
bound is never lost because it is encoded in the type,
while the  __builtin_dynamic_object_size is extremely
useful to enhance existing code bases, but is best
effort only.

So I think we should do both.

...
> 
> > > > > It also has the benefit of
> > > > > allowing one to reference a variable not in the structure:
> > > > > 
> > > > > const int items;
> > > > > struct object {
> > > > >     ...
> > > > >     char items;
> > > > >     ...
> > > > >     struct inner {
> > > > >         ...
> > > > >         int flex[] __attribute__((__element_count__(items))); /* 
> > > > > References
> > > > > global "items" */
> > > > >     };
> > > > > } *ptr;
> > > > 
> > > > Whether you allow this or not has nothing to do with the syntax.
> > > > 
> > > > The question is what semantics you attach to this and this is
> > > > also a question in your example. 
> > > > 
> > > > If you define
> > > > 
> > > > struct inner* a = ...
> > > > 
> > > > What does it say for  a->flex  ?
> > > > 
> > > I need to point out that I used "offsetof" only as an example. It's 
> > > possible to
> > > create something more robust which will carry along type information, 
> > > etc.,
> > > which the current offsetof macro throws away. I should have made that 
> > > clear.
> > > 
> > > The sanitizers that see "a->flex" will try to find the correct variable. 
> > > If
> > > they can't, then they won't generate a check. In the case of it 
> > > referencing a
> > > non-field member, it'll use that if it's within scope. If it refers to a 
> > > field
> > > member of a parent container that's not within scope, it'll also not 
> > > generate a
> > > check. It's unfortunate that these checks are done as a "best effort," 
> > > but it
> > > could lead to software changes to improve security checks (like passing a
> > > parent structure into a function rather than an inner structure.
> > 
> > Yes. We could also have an optional warning which warns about accessing
> > 'flex' in a context where 'items' is not accessible.  My point is that
> > this feature of potentially referring to stuff which may not be accessible
> > in all cases makes implementation more complicated.
> > 
> It does make it more complicated, that's true.
> 
> I haven't seen comments on Kees's first example, where "malloc" returns an
> "__alloc_size" hint that's lost when "p" is returned from the function (at
> least in Clang). If that information is kept around, it would expand the 
> number
> of bounds checks we could perform. (Kudos if this is currently the case in
> GCC.)

I think not.  But this would not work across TU boundaries anyway.

https://godbolt.org/z/eW9GT579r

Martin

Reply via email to