From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id D886A3858D35 for ; Tue, 7 Feb 2023 19:17:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D886A3858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.97,278,1669104000"; d="scan'208";a="96130278" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 07 Feb 2023 11:17:48 -0800 IronPort-SDR: n2YJHEGeRWOZ5zfZUU9gEV2eOQDA8PWHGQymVysjPQAfDLJOmrFCgRMZVEBZ7xVSi6NVKLBMj6 hJCvFvIUtpiFPm1248b1IdvoOlPNKgKLPUo1dAS+wDqe3rbiMxTKyU4AyO2D/BFL7b3B+KG8QS jhuNRiYKxonZe9+RtXbIGWPiyD/I7L8fHhgmAe4fDPI6Ek+R7wfaikyA7tM7VrjiZZYfJETSq9 vrNtvii/qAUOEB31R+AwOGJanQ8JWgzjuFldWYrbXXTKkcqjuCyiAdUwpNisGYCIEZpZ7TMVdd w8Y= Date: Tue, 7 Feb 2023 19:17:29 +0000 From: Joseph Myers To: Qing Zhao CC: Richard Biener , "gcc-patches@gcc.gnu.org" , "siddhesh@gotplt.org" , "keescook@chromium.org" Subject: Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] In-Reply-To: <367EBE15-1675-4D29-A9C2-A4A57FA4DB62@oracle.com> Message-ID: <2184ee29-9a36-e85-11c5-81c47aa22055@codesourcery.com> References: <20230131141140.3610133-1-qing.zhao@oracle.com> <20230131141140.3610133-2-qing.zhao@oracle.com> <812910BC-870E-4432-870D-538024F1A510@oracle.com> <3B30CFBF-5004-41A4-940D-1F23C010403B@oracle.com> <4E515AA5-2069-497E-A301-EC8ED744E780@oracle.com> <367EBE15-1675-4D29-A9C2-A4A57FA4DB62@oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-418792953-1675797449=:1298172" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3108.5 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: ---1152306461-418792953-1675797449=:1298172 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote: > 1. Structure with flexible array member embedded into other structures > recursively, for example: > > struct A { > int n; > char data[]; > }; > > struct B { > int m; > struct A a; > }; > > struct C { > int q; > struct B b; > }; > > In the above, “struct C” will not be caught by this routine. Because struct B is diagnosed with -pedantic when it embed struct A, there is no need for -pedantic to diagnose struct C as well when it embeds struct B. > 2. Only C99 standard flexible array member be included, [0] and [1] are > not included, for example: Obviously we can't diagnose use of structures with [1] trailing members, because it's perfectly valid to embed those structures at any position inside other structures. And the same is the case for the [0] extension when it's used to mean "empty array" rather than "flexible array". Note that my comments above are about what diagnostics are appropriate under the standard. They are *not* about how code generation might allow for possible uses of certain source code constructs as if they were flexible array members. The two contexts may very well require different notions of what counts as a flexible array member. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-418792953-1675797449=:1298172--