From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 0D0FF385842E for ; Wed, 15 Mar 2023 03:26:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0D0FF385842E 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.98,261,1673942400"; d="scan'208";a="104393500" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 14 Mar 2023 19:26:30 -0800 IronPort-SDR: 2g3MQYCxIgYVVJfe84Y/7tIFBoT/TAMs6YSKKkckh6Fx0g8kYEZdQVVaPGQpS7sagSPKbojK8I H0OQYQ4JeYuXdao/evJImFTxsCBJqfIlOSYzd5AyT3KUt0Fag/LJBdDmutc8Gt1bOPUQI4Rp5P pNbcxoHIS4GjSYsBmNQMKo+IWohi6XF6qbIk/lSAh3UYnzxIf75LvJEEXsYlM8F/koiNY0Kb8C WMkplfpfaDTDaPAuxsQxwkPWndMPvaGMOLCrt5sCxMrHGSy5nWyqDosSJP7cO3L6PyVZVInBv4 /Rg= Message-ID: <695e926a-25a5-7cc5-c2e1-debff1c6ff5d@codesourcery.com> Date: Tue, 14 Mar 2023 21:26:27 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [V4][PATCH 2/2] Update documentation to clarify a GCC extension Content-Language: en-US To: Qing Zhao , , CC: , , References: <20230224183505.4112295-1-qing.zhao@oracle.com> <20230224183505.4112295-3-qing.zhao@oracle.com> From: Sandra Loosemore In-Reply-To: <20230224183505.4112295-3-qing.zhao@oracle.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-11.mgc.mentorg.com (147.34.90.211) To svr-orw-mbx-13.mgc.mentorg.com (147.34.90.213) X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2/24/23 11:35, Qing Zhao via Gcc-patches wrote: > gcc/c-family/ChangeLog: > > * c.opt: New option -Wgnu-variable-sized-type-not-at-end. > > gcc/c/ChangeLog: > > * c-decl.cc (finish_struct): Issue warnings for new option. > > gcc/ChangeLog: > > * doc/extend.texi: Document GCC extension on a structure containing > a flexible array member to be a member of another structure. > > gcc/testsuite/ChangeLog: > > * gcc.dg/variable-sized-type-flex-array.c: New test. I'm only a documentation (and nios2) maintainer so I cannot approve adding a new option or warning. I was going to review the documentation parts, at least, but I think this proposal is technically flawed because it is trying to document something that is undefined behavior in ways that it doesn't actually behave on all targets. > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index c1122916255..e278148c332 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -1748,7 +1748,53 @@ Flexible array members may only appear as the last member of a > A structure containing a flexible array member, or a union containing > such a structure (possibly recursively), may not be a member of a > structure or an element of an array. (However, these uses are > -permitted by GCC as extensions.) > +permitted by GCC as extensions, see details below.) > +@end itemize > + > +GCC extension accepts a structure containing an ISO C99 @dfn{flexible array > +member}, or a union containing such a structure (possibly recursively) > +to be a member of a structure. > + > +There are two situations: > + > +@itemize @bullet > +@item > +The structure with a C99 flexible array member is the last field of another > +structure, for example: > + > +@smallexample > +struct flex @{ int length; char data[]; @}; > +union union_flex @{ int others; struct flex f; @}; > + > +struct out_flex_struct @{ int m; struct flex flex_data; @}; > +struct out_flex_union @{ int n; union union_flex flex_data; @}; > +@end smallexample > + > +In the above, both @code{out_flex_struct.flex_data.data[]} and > +@code{out_flex_union.flex_data.f.data[]} are considered as flexible arrays too. > + > + > +@item > +The structure with a C99 flexible array member is the middle field of another > +structure, for example: > + > +@smallexample > +struct flex @{ int length; char data[]; @}; > + > +struct mid_flex @{ int m; struct flex flex_data; int n; @}; > +@end smallexample > + > +In the above, @code{mid_flex.flex_data.data[]} is allowed to be extended > +flexibly to the padding. E.g, up to 4 elements. I think this paragraph is incorrect; how GCC lays out this structure depends on the target and ABI. Looking at output from a GCC 12 nios2-elf build I have handy, I see it is in fact laying out mid_flex so that member n is at the same address at offset 8 as flex_data.data[0], which is not useful at all. > +However, relying on space in struct padding is a bad programming practice, > +compilers do not handle such extension consistently, Any code relying on > +this behavior should be modified to ensure that flexible array members > +only end up at the ends of structures. > + > +Please use warning option @option{-Wgnu-variable-sized-type-not-at-end} to > +identify all such cases in the source code and modify them. This extension > +will be deprecated from gcc in the next release. My suggestion would be to make this a hard error instead of a warning, unless there is some real body of code out there that depends on this feature on a target that actually does insert padding. If it's a warning, it ought to be enabled by default. And, rather than trying to document the behavior, the manual should just say it's undefined. -Sandra