From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EACD93858C53; Thu, 2 Mar 2023 19:47:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EACD93858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677786476; bh=tpLvHsSbO+xUyKGaRvBpYWxe573qrr3omk1Y9tSOfwo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ss9oE9P8adI/n2aGe0n8zy1L7amg1oALaVFEwGZeqlcP9hBSGGAQuzAtSQq5NODnM Liaofq8xTW/xisLQ14p0Sfvzs/AuEdHmltbK269A1btNcQiLSw/6D6DtdymxlJNAHB EHNn1didwEYuWWeYcs5E4rZUoGMG64WvNgUCgNj4= From: "qinzhao at gcc dot 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 19:47:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: qinzhao at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: qinzhao at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108896 --- Comment #11 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #9) >=20 > https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log thanks for the info.=20 >=20 > But we made variably modified types mandatory in C23 to > help with bounds checking and this already works quite > nicely with GCC / Clang: >=20 > https://godbolt.org/z/ddfsdWPMj nice! can you provide a pointer to the section in C23 that made this change? >=20 > > when this variable length concept is extended to global scope, not sure= how to > > implement the size expression? need some study here. >=20 > Here, we want to use a member of the struct as a size=C2=A0 > 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. >=20 > 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. >=20 > 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? then we can just borrow Ada's implementation idea to implement this in C if this is approved as an GCC extension for C.=20 > > this proposal basically is to extend the VLA concept from function scop= e to > > global scope. is my understanding correct? >=20 > I would say the idea is to allow size expressions to refer > to member of a struct instead of only automatic variables. >=20 Okay. > > a question here is: > >=20 > > for the following nested structure:=20 > >=20 > > struct object { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0... > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0char items; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0... > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct inner { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0... > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0int flex[]; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}; > > } *ptr; > >=20 > > what kind of syntax is good to represent the upper bound of "flex" in t= he inner > > struct with "items" in the outer structure? any suggestion? >=20 > 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. >=20 Okay.=