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: Thu, 02 Mar 2023 20:07:19 +0000	[thread overview]
Message-ID: <bug-108896-4-CyG9r4ONyt@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 #13 from Martin Uecker <muecker at gwdg dot de> ---
Am Donnerstag, dem 02.03.2023 um 19:47 +0000 schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> 
> --- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #9)
> > 
> > https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
> thanks for the info. 
> > 
> > But we made variably modified types mandatory in C23 to
> > help with bounds checking and this already works quite
> > nicely with GCC / Clang:
> > 
> > https://godbolt.org/z/ddfsdWPMj
> nice!
> can you provide a pointer to the section in C23 that made this change?

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

UBSan support in GCC to diagnose such out of bounds accesses
was added here:

https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=04fd785e38c4c37ae4f71704397a27a924baf4d9

> > 
> > > when this variable length concept is extended to global scope, not sure how to
> > > implement the size expression? need some study here.
> > 
> > Here, we want to use a member of the struct as a size 
> > expression. This could work equally at function and file scope.
> > But the semantics need to be worked out.  I have started to work
> > on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
> > but did not get very far.
> > 
> > The idea is to evaluate the size expression whenever the member
> > with the size is accesses. If the size is not set before, this
> > would be undefined behavior.
> > 
> > Other languages such as Ada support this, so in principle this
> > should be a piece of cake.

> Oh, Ada can support this already?
> how does Ada implement this?

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.


> then we can just borrow Ada's implementation idea to implement this in C if
> this is approved as an GCC extension for C. 

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.

But I am still trying to understand how this all works in GCC.


Martin

  parent reply	other threads:[~2023-03-02 20:07 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 [this message]
2023-03-03 20:27 ` isanbard at gmail dot com
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

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-CyG9r4ONyt@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).