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 1719838582BC; Wed,  8 Mar 2023 19:47:45 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1719838582BC
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678304866;
	bh=4BWufMf4FgNVPuAxWVezoKMUFOuF9wmn0MK/X7N7iWo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=iY8Js8S0zu2AI0WhXqKiB2QsUiGYsPBA/WwZJLUopa4QesrT0gi6huRiPVDqGcI3q
	 GZ13OH2KW6zJVOUEEtKLooD2ANHJDsKiQAtV2zKfU0Gi5oJpZtT7psWG0ivUYysZmU
	 JSonawncdCEET/vTyrJyVGm+bTUvwe4+96RfyAYQ=
From: "qinzhao at gcc dot gnu.org" <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: Wed, 08 Mar 2023 19:47:45 +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: <bug-108896-4-gLjqv5rExI@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 #31 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #29)
> > however, I think that both the new attribute and the new C syntax exten=
sion
> > should support the similar user interface. We might need to decide on t=
his
> > first.
>=20
> I think there are some fundamental differences: In one
> case the size is encoded into the type and in the other
> it is just an annotation that can be ignored.

Yes, understood.

I might not make myself clear in the previous message. what I mean by the "=
the
similar user interfaces" is:

both might support the following:

1. a declared variable as the size:

**C syntax extension:
unsigned int length;
struct object {
   int others;
   char flex[length];=20=20
}

**corresponding attribute:
unsigned int length;
struct object {
   int others;
   char flex[] __attribute__((__element_count__(length)));=20=20
}

2. a declared field of the same structure as the size:
**C syntax extension:
struct object {
   unsigned int length;
   char flex[.length];=20=20
}

**corresponding attribute:
struct object {
   unsigned int length;
   char flex[] __attribute__((__element_count__(.length)));=20=20
}

3. expressions including declared variables and declared fields of the same
structure as the size:

**C syntax extension:
unsigned int item;
struct object {
   unsigned int ratio;
   char flex[item * .ratio];=20=20
}

**corresponding attribute:
unsigned int item;
struct object {
   unsigned int ratio;
   char flex[] __attribute__((__element_count__(item * .ratio)));=20=20
}

Not sure on the following case:

4. a declared field of the containing structure as the size:

**C syntax extension:
struct object {
   unsigned int length;
   struct inner {
=C2=A0=C2=A0=C2=A0  ...
=C2=A0=C2=A0=C2=A0  int flex[..length];
=C2=A0=C2=A0=C2=A0};
}

**corresponding attribute:
struct object {
   unsigned int length;
   struct inner {
     ...
     char flex[] __attribute__((__element_count__(..length)));
   }=20=20
}

what else from the user's point of view?
>=20
> >=20
> > right now, the user interface we cannot agreed on is:
> >=20
> > whether we should support the following nested annotation (either with
> > attribute or with the C syntax extension):
> >=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=A0unsigned int 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
> I am fine with supporting it, but one needs to decide
> on the semantics in the case where inner is not accessed
> via the outer struct.
Yes, that's right.=