From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6EC533850877; Wed, 8 Mar 2023 16:57:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6EC533850877 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678294625; bh=cfMFpjwVK4RcTfpV8XhdOh6zXIq/gj5nSlZFxMma40M=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RtNTMVYzNQJP93+pyWMLC0loU477unNR7JP8vO+u5cPexTK9n4sHGhFoPYttIm6NP lUMu73moy6YjzQLIzCYpHd+xWa61m9EqNZ2WJ67ih7oP9gFQlH/LZOze9c59IUDWe7 pBd8wkRWsVx/MRFwucfzdXd8pksBSp46ABGqzPqw= 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 16:56:59 +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 #23 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #13) >=20 > VLAs and VM types exist since C99 and were made optional in C11. > The minimal change we adopted to make support for VM types=C2=A0 > (but not VLAs) mandatory again was: >=20 > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf So, this will be official in C23? i.e, VM types will be mandatory, but VLA = will be optional (and later might be deprecated?) >=20 > I think using PLACEHOLDER_EXPR that are insert into the size > expression and then replaced later by the struct being accessed,=C2=A0 > e.g. >=20 > struct foo { > int len; > char buf[PLACEHOLDER_EXPR.len] > }; >=20 > and then later when we have >=20 > struct foo x; >=20 > x->buf >=20 > we would replace in the size of the type for x->buf the placeholder > with x itself. I see. Yes, this will resolve the implementation difficulty for filling the size of the FAM field when the size is the previous declared field in the s= ame structure.=20 > Yes, this was what I wanted to do... My main use case is not flexible > array members but VM types in struct: >=20 > struct foo { > int len; > char (*buf)[.len]; > }; >=20 >=20 > This has less issues because the size of the struct then does not depend > on the length. a little confused here: what's the definition of VM type? it's size will not depend on the ".len" ?=