From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 5F9103858C5E; Fri,  3 Mar 2023 20:28:00 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5F9103858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1677875280;
	bh=rR2xEnzFprWj8H61nI3I3RI1bLL2d1p42hcv9MGProQ=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=v9DXlv2MSYR6UHOWQdZUWzum45dK/RRZqIVLIKhrEB0epuzX7etwotB1xQI1y0Z7D
	 vSq4etgzGknXXKr0Otjx09wsQkFqK0esqEBryro1hEQPkOUybJX1gemAv6THLXyzZC
	 razS105nmdVrZLtkYYQj6KDczi4oCKx+onS2cdVU=
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
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: isanbard at gmail dot com
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: <bug-108896-4-cJ7EOSdtna@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-108896-4@http.gcc.gnu.org/bugzilla/>
References: <bug-108896-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108896

--- 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
> > >=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 similar =
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 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

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 designa=
ted
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=