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 256DF3858035; Mon,  6 Mar 2023 19:57:26 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 256DF3858035
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1678132646;
	bh=ykQ4hGcshImwP5QMvX/WjF3mavA28RJ4J0JFDJALccI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=oFp+aleScd1NPBlrMQoaU5DQxTeiJCxpb+zE87lJIUMJTmBbiOEi/DzihH9Jm0N9f
	 7wsDas5nzHQS/YbFRk61IdiO59JTRYqxLUq1c0qZQz2p2D8iCkLbpzZ071ESpuwIjk
	 M42JFoIZ0BR0XlpkLPEVKmZGgLVW/H7Y/OG+gODU=
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: Mon, 06 Mar 2023 19:57:25 +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: <bug-108896-4-zuUauO35NZ@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 #21 from Martin Uecker <muecker at gwdg dot de> ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Bill Wendling from comment #18)
> > > This is not the case in C: https://godbolt.org/z/P7M6cdnoa
> > >=20
> > Right, it's not legal C syntax. I wanted to point out that it's not an
> > impossible syntax. The lexer and parser have no idea of, nor should they
> > care about, legal types, complete struct definitions, etc. All it sees =
is a
>=20
> They do though, in lots of ways.  The reason it works in C++ is that the
> language
> explicitly requires it and the parser just needs to save token sequences =
of
> NSDMIs and
> member functions defined inside of class and parse them when the class is
> complete.
> We don't want to do that in C.

For the parser I have a prototype. It only works for size expressions using
members that came before in the source and not members which are not yet
declared. For flexible array members this is sufficient. It works by storing
the field decl in a list during declaration of struct and then uses the lis=
t to
lookup the field decl in build_component_ref.=20

Martin=