From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 5DE7F3857400; Wed, 8 Mar 2023 17:36:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5DE7F3857400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678296999; bh=Krb2uU8t68+kQWq0a0fWRJV0GDtN/Kryj1/ddzraKFI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fyLVJ3G6Rbn/MvOuiUMecY2VwQTOh5viRSovbL1DV5FYuPASVvH28MV7NnCluQDs/ Lv+Y7tPoDhkZSkZLn0kUrRuF5IC0XyG2ox2W0i7vsNCKbCrgfER/kwddHqqXNEE4Je FI83PL3F7SkgTSlondd4O3hh8ozo/DfvwJ/o/T24= 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: Wed, 08 Mar 2023 17:36:39 +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 #25 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #17) > The syntax with the dot would make it not conflict. But I need > this for this use case >=20 > struct foo { > int count; > int (*buf)[.count]; > }; >=20 > so that ARRAY_SIZE(*foo->buf) works correctly and also accesses > to foo->buf are bounds checkked. So it would make sense to=C2=A0 > solve to treat flexible array members in the same way. Yes, I agree.=20 then the size of the array type (even though it's not a constant) will be embedded in the TYPE consistently. therefore simplify compiler's implementa= tion and make it consistently.=20 >=20 > But I agree that we should simply add the attribute now also > because it makes it possible to use it for existing code bases. Yes.=