From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D33723857B84; Mon, 13 Jun 2022 18:12:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D33723857B84 From: "kees at outflux dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails Date: Mon, 13 Jun 2022 18:12:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: kees at outflux dot net X-Bugzilla-Status: NEW 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2022 18:12:09 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101836 --- Comment #19 from Kees Cook --- (In reply to Martin Sebor from comment #18) > The zero size case exists (and is documented) solely as a substitute for > flexible array members. Treating is as an ordinary array would disable t= hat > extension. It might be appropriate to provide a separate option to contr= ol > it but conflating it with the other cases (one or more elements) doesn't > seem like the robust design. >=20 > As I mentioned in the review of the Clang change, > https://reviews.llvm.org/D126864, so that code bases that use some larger > number of elements than zero, such as one, and that can't easily change, = can > still benefit from the BOS enhancement for the remaining cases, it would = be > helpful for the new option to accept the minimum number of elements at wh= ich > a trailing array ceases to be considered a poor-man's flexible array memb= er. I see your point about gaining the "trailing array" fix without breaking the older code bases, but that doesn't seem to fit the name (nor purpose) of -fstrict-flex-arrays, which should be considered a "complete" fix. To me it looks like -fstrict-flex-arrays should kill the [0] extension, the ancient [1] misuse, and the "anything trailing is flex" logic. If fixing _o= nly_ the latter is desired, perhaps add an option for that, but no one is actual= ly asking for it yet. :) The Linux kernel wants the "fully correct" mode.=