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
next prev 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: linkBe 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).