From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 70C4F3858404; Tue, 4 Apr 2023 20:08:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70C4F3858404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680638919; bh=FgltjE+4SFjsmzMAznUm0e83UodAKfQZPVgsX0Z2Q7s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=NcUFq5FrIpOZue0xuhu4L5soDSF3wDPZk8TMCqe3WY8JFGeJKYPNsDmZl8C++KAkU CDhvsYTPR9FlnEybSDW+BVAyI68xnIQAoJ1NWN6WqhiDvaVbL7ymUIjH0061SJIbX/ p2nL/MQ3C/u/SUYMzBzk5S6SLKSUMoQrhyFlcVkE= 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: Tue, 04 Apr 2023 20:08:38 +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 #39 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #38) > struct foo { > int n; > char (*buf)[.n]; > }; >=20 > void store(struct foo* p, int a, int b) { (*p->buf)[a] =3D b; } >=20 > int main() > { > struct foo p =3D { 7, &(char[7]){ 0 } }; > store(&p, 7, 1); > } >=20 > With UBSan, this should give this error: > ex.c:8:52: runtime error: index 7 out of bounds for type 'char [*]' yes, this worked. and with -fdump-tree-gimple, I can see the IR representat= ion for this test case. thanks. > In the parser for '.n' I create a component ref with a placeholder > expression inside it. But then later when creating a component > ref for p->buf I replace all placeholder expressions in the > *type* of p->buf with *p. So the type of p->buf has a > .n as size expression somewwere and this=C2=A0 > becomes p.n. the above explanation is very clean. thanks. but the thing that confused me is: is the *type* of p->buf Pointer or Array= ?=20 >From the source code, it's a pointer, right? if so, why embed the array siz= e to it? > Yes, potentially. But a FAM has special semantics and the > code for this detects this based on the missing size (I think). Yes, that's true. currently, we determine a FAM as the following (c-decl.cc= ): /* Determine whether TYPE is a ISO C99 flexible array memeber type "[]". */ static bool flexible_array_member_type_p (const_tree type) { if (TREE_CODE (type) =3D=3D ARRAY_TYPE && TYPE_SIZE (type) =3D=3D NULL_TREE && TYPE_DOMAIN (type) !=3D NULL_TREE && TYPE_MAX_VALUE (TYPE_DOMAIN (type)) =3D=3D NULL_TREE) return true; return false; } So, if we want to change the syntax of FAM to include size info, and embedd= ed this size info to the TYPE, then we need to adjust all the places in FE or = in Middle end that depend on the current FAM IR. Yes, potentially much bigger changes.=20 therefore, directly extending the FAM syntax to include the size info might involve bigger change than attribute approach.=20 We can implement attribute first, and then later do the syntax extension.=20 that might be safer.=20 > I tried the other thing first, because it seemed simpler and > could potentially serve as a basis for the FAM case. But I am > not so sure anymore, because of the issue mentioned below. Okay, I see now. > For the FAM case we should probably attach the attribute > to the member and read it directly in the object size pass, > similar how this is now done for the access attributes for > parameters. Yes, implementation of attribute should be simpler and safer.=20 I will try to come up with a patch on this attribute.=20 >=20 > I also thought that passing the information via the type > would be better, but I am not sure how to do this at the > moment. Yes, passing the Size info through the type will be better, we can implement this syntax extension later if the attribute works very well, and we can promote it to a real language standard at that time.=