public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "muecker at gwdg dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
Date: Fri, 03 Mar 2023 21:32:42 +0000	[thread overview]
Message-ID: <bug-108896-4-nb3NpT67Fu@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108896-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #15 from Martin Uecker <muecker at gwdg dot de> ---
Am Freitag, dem 03.03.2023 um 20:27 +0000 schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> 
> --- Comment #14 from Bill Wendling <isanbard at gmail dot com> ---
> (In reply to Martin Uecker from comment #9)
> > > > Considering that the GNU extensions is rarely used, one could consider
> > > > redefining the meaning of
> > > > 
> > > > int n = 1;
> > > > struct {
> > > >   int n;
> > > >   char buf[n];
> > > > };
> > > > 
> > > > so that the 'n' refers to the member. Or we add a new syntax similar to
> > > > designators (which intuitively makes sense to me).
> > > designator might be better IMO.
> > > 
> > > a question here is:
> > > 
> > > for the following nested structure: 
> > > 
> > > struct object {
> > >         ...
> > >         char items;
> > >         ...
> > >         struct inner {
> > >                 ...
> > >                 int flex[];
> > >         };
> > > } *ptr;
> > > 
> > > what kind of syntax is good to represent the upper bound of "flex" in the inner
> > > struct with "items" in the outer structure? any suggestion?
> > 
> > I would disallow it. At least at first. It also raises some
> > questions: For example, one could form a pointer to the inner
> > struct, and then it is not clear how 'items' could be accessed
> > anymore.
> > 
> 
> That would be limiting its use in the Linux kernel. It seems that there are
> ways to refer to struct members already using something like "offsetof":
> 
> struct object {
>     ...
>     char items;
>     ...
>     struct inner {
>         ...
>         int flex[] __attribute__((__element_count__(offsetof(struct object,
> items))));
>     };
> } *ptr;

This seems to be something completely different. offsetof
computes the offset from the type given in its argument.
But it would not access the value of the member of the
enclosing struct. But it would not work in your example,
because the struct object is incomplete at this point.

So no, you can not use offsetof to reference a member
of an enclosing struct.

> 
> The object referenced by "offsetof" would be from the containing structure (see
> "container_of" macro in Linux).
> 
> It has the benefit of not needing to extend C's syntax to allow for designated
> initializers outside of initialization lists. 

Yes, but that syntax would be intuitive which I would see
as an advantage.

But I am not saying we shouldn't have the attribute first.


> 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  ?


Martin










>

  parent reply	other threads:[~2023-03-03 21:32 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-22 21:26 [Bug c/108896] New: " kees at outflux dot net
2023-02-22 21:31 ` [Bug c/108896] " kees at outflux dot net
2023-02-22 21:32 ` pinskia at gcc dot gnu.org
2023-02-23  8:44 ` rguenth at gcc dot gnu.org
2023-02-23  9:10 ` jakub at gcc dot gnu.org
2023-02-24 15:44 ` muecker at gwdg dot de
2023-03-01 22:54 ` qinzhao at gcc dot gnu.org
2023-03-01 23:27 ` kees at outflux dot net
2023-03-02 15:50 ` muecker at gwdg dot de
2023-03-02 17:34 ` qinzhao at gcc dot gnu.org
2023-03-02 18:17 ` muecker at gwdg dot de
2023-03-02 18:34 ` muecker at gwdg dot de
2023-03-02 19:47 ` qinzhao at gcc dot gnu.org
2023-03-02 19:56 ` qinzhao at gcc dot gnu.org
2023-03-02 20:07 ` muecker at gwdg dot de
2023-03-03 20:27 ` isanbard at gmail dot com
2023-03-03 21:32 ` muecker at gwdg dot de [this message]
2023-03-03 23:18 ` isanbard at gmail dot com
2023-03-04  7:52 ` muecker at gwdg dot de
2023-03-06 19:15 ` isanbard at gmail dot com
2023-03-06 19:18 ` jakub at gcc dot gnu.org
2023-03-06 19:38 ` muecker at gwdg dot de
2023-03-06 19:57 ` muecker at gwdg dot de
2023-03-06 20:05 ` siddhesh at gcc dot gnu.org
2023-03-08 16:56 ` qinzhao at gcc dot gnu.org
2023-03-08 17:13 ` qinzhao at gcc dot gnu.org
2023-03-08 17:36 ` qinzhao at gcc dot gnu.org
2023-03-08 17:38 ` qinzhao at gcc dot gnu.org
2023-03-08 17:43 ` qinzhao at gcc dot gnu.org
2023-03-08 17:48 ` muecker at gwdg dot de
2023-03-08 18:37 ` muecker at gwdg dot de
2023-03-08 19:20 ` qinzhao at gcc dot gnu.org
2023-03-08 19:47 ` qinzhao at gcc dot gnu.org
2023-03-08 20:20 ` muecker at gwdg dot de
2023-03-08 20:47 ` qinzhao at gcc dot gnu.org
2023-03-29 16:12 ` muecker at gwdg dot de
2023-04-03 20:29 ` qinzhao at gcc dot gnu.org
2023-04-03 21:53 ` muecker at gwdg dot de
2023-04-04 15:07 ` qinzhao at gcc dot gnu.org
2023-04-04 16:33 ` muecker at gwdg dot de
2023-04-04 20:08 ` qinzhao at gcc dot gnu.org
2023-04-19 16:32 ` qinzhao at gcc dot gnu.org
2023-05-03 13:57 ` qinzhao at gcc dot gnu.org
2023-05-03 15:32 ` kees at outflux dot net
2023-05-04 15:16 ` muecker at gwdg dot de
2023-05-04 15:30 ` qinzhao at gcc dot gnu.org
2023-05-25 18:14 ` qinzhao at gcc dot gnu.org
2023-05-25 18:47 ` ndesaulniers at google dot com
2023-10-05 19:54 ` tg at mirbsd dot org
2023-10-05 20:21 ` muecker at gwdg dot de
2023-12-27  6:31 ` sean@rogue-research.com
2024-03-06 14:40 ` qinzhao at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-108896-4-nb3NpT67Fu@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).