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 9A29E38582BD for ; Wed, 7 Jun 2023 22:05:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A29E38582BD 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="6.00,225,1681200000"; d="scan'208";a="8183304" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 07 Jun 2023 14:05:33 -0800 IronPort-SDR: qVZ6E/frPLhpIIoyA0rgtppK1gX082v5n912Dw9xLabV9/3SE0I0eMapr6E+hLGloBSzJmTHT3 Y7i9gblzH+TcnMe88nZJ0JbORCN/iVzl2nn0ZwlabbXR3fucgnTOr2Z9LzHNidX88/Hvrx4f9c uWP/9lvfNpGaAOhNob4p4QnAh57rhNFUJ50ylKXSx1a45mc59QB3RPrSHr2y0zGZ6jVy0dvsOu PZoWdh8EMS3/w0f7/Ud30HwcIcIvBXsNnZmT0/897jMfHQvYeSHuzYGFdjbfS3lCfKowDJGSRM ByU= Date: Wed, 7 Jun 2023 22:05:28 +0000 From: Joseph Myers To: Qing Zhao CC: "richard.guenther@gmail.com" , "jakub@redhat.com" , "gcc-patches@gcc.gnu.org" , "keescook@chromium.org" , "siddhesh@gotplt.org" , "uecker@tugraz.at" , "isanbard@gmail.com" Subject: Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896) In-Reply-To: <4F824ECC-6ACC-434A-8887-0CB44D0B3CDA@oracle.com> Message-ID: <5616c54-65c8-c3c-714-7fef81501a60@codesourcery.com> References: <20230525161450.3704901-1-qing.zhao@oracle.com> <20230525161450.3704901-2-qing.zhao@oracle.com> <28BEA1DA-5277-493D-8C85-1C204AD1B70F@oracle.com> <4F824ECC-6ACC-434A-8887-0CB44D0B3CDA@oracle.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-1349005822-1686175528=:511061" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3106.2 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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-1349005822-1686175528=:511061 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8BIT On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote: > Are you suggesting to use identifier directly as the argument of the attribute? > I tried this in the beginning, however, the current parser for the attribute argument can not identify that this identifier is a field identifier inside the same structure. > > For example: > > int count; > struct trailing_array_7 { > Int count; > int array_7[] __attribute ((element_count (count))); > }; > > The identifier “count” inside the attribute will refer to the variable > “int count” outside of the structure. c_parser_attribute_arguments is supposed to allow an identifier as an attribute argument - and not look it up (the user of the attribute would later need to look it up in the context of the containing structure). Callers use attribute_takes_identifier_p to determine which attributes take identifiers (versus expressions) as arguments, which would need updating to cover the new attribute. There is a ??? comment about the case where the identifier is declared as a type name. That would simply be one of the cases carried over from the old Bison parser, and it would seem reasonable to remove that special-casing so that the attribute works even when the identifier is declared as a typedef name as an ordinary identifier, since it's fine for structure members to have the same name as a typedef name. Certainly taking an identifier directly seems like cleaner syntax than taking a string that then needs reinterpreting as an identifier. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-1349005822-1686175528=:511061--