From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 77C493858C5E; Fri, 3 Mar 2023 21:32:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 77C493858C5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677879162; bh=NAZN61eV2G+kYHuP6LMr7haABBrgu2/9xLtdULW9bh0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YgtkaJU4BWkPFZogZVw7NeaUFuFXTs579UI7q06ZkN0XquZ7yz9Mim34Znv03zIvv N4LCgETroRxlIwRPZdK8gM6dYSz10v/Gs/XY18s4iJ2wSdpJATeUYwSQaZaJNeXgwY fh/aW25lvV3+kxrdAStcP2nA47OPjHpASOAS2eqw= From: "muecker at gwdg dot de" 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 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: muecker at gwdg dot de 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 #15 from Martin Uecker --- 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=3D108896 >=20 > --- Comment #14 from Bill Wendling --- > (In reply to Martin Uecker from comment #9) > > > > Considering that the GNU extensions is rarely used, one could consi= der > > > > redefining the meaning of > > > >=20 > > > > int n =3D 1; > > > > struct { > > > > =C2=A0=C2=A0int n; > > > > =C2=A0=C2=A0char buf[n]; > > > > }; > > > >=20 > > > > so that the 'n' refers to the member. Or we add a new syntax simila= r to > > > > designators (which intuitively makes sense to me). > > > designator might be better IMO. > > >=20 > > > 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= the 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 >=20 > That would be limiting its use in the Linux kernel. It seems that there a= re > ways to refer to struct members already using something like "offsetof": >=20 > struct object { > =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=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=A0int flex[] __attribute__(= (__element_count__(offsetof(struct object, > items)))); > =C2=A0=C2=A0=C2=A0=C2=A0}; > } *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. >=20 > The object referenced by "offsetof" would be from the containing structur= e (see > "container_of" macro in Linux). >=20 > It has the benefit of not needing to extend C's syntax to allow for desig= nated > initializers outside of initialization lists.=C2=A0 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: >=20 > const int items; > struct object { > =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=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=A0int flex[] __attribute__(= (__element_count__(items))); /* References > global "items" */ > =C2=A0=C2=A0=C2=A0=C2=A0}; > } *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.=20 If you define struct inner* a =3D ... What does it say for a->flex ? Martin >=