public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "isanbard at gmail dot com" <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 20:27:58 +0000	[thread overview]
Message-ID: <bug-108896-4-cJ7EOSdtna@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 #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;

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. 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;

-bw

  parent reply	other threads:[~2023-03-03 20:28 UTC|newest]

Thread overview: 53+ 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 [this message]
2023-03-03 21:32 ` muecker at gwdg dot de
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
2024-05-31 17:50 ` 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-cJ7EOSdtna@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).