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 C4E3B3858D35 for ; Fri, 16 Jun 2023 16:21:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4E3B3858D35 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,247,1681200000"; d="scan'208";a="10114929" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 16 Jun 2023 08:21:34 -0800 IronPort-SDR: rnAjblb2kBnXu77snTISHBxM969VlcpGBxbaTwDP3yemJJAK0qWkSQ3AphSHwnkj0FL/VQVB83 jBUuQire0yWFV7BiJIi0Th7NZC26SeNkWmNtrqc4JrzXgs42gB4dC7FeJZ8Hvd4z6X5n05J9sR NY6FMow1FIcDOtAeiM0C+Kt9xn4alNDk/D9VeD/t/SUwCym4vE2acHNIJt0f5N8y4n7dEsRl0Q 5AqnGBpzLatDS12jo52kqHwmWFTohlMLIFYxutmbpnEIJlvbf1XiMGyc1DbU9w2e9xe87kzUwe Qss= Date: Fri, 16 Jun 2023 16:21:29 +0000 From: Joseph Myers To: Martin Uecker CC: Qing Zhao , Qing Zhao via Gcc-patches , "richard.guenther@gmail.com" , "jakub@redhat.com" , "keescook@chromium.org" , "siddhesh@gotplt.org" , "isanbard@gmail.com" Subject: Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896) In-Reply-To: Message-ID: <6068bad0-a0c4-3f41-6640-9d3b062794f@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> <5616c54-65c8-c3c-714-7fef81501a60@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-557406811-1686932489=:41305" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-3106.0 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-557406811-1686932489=:41305 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote: > > Note that no expressions can start with the '.' token at present. As soon > > as you invent a new kind of expression that can start with that token, you > > have syntactic ambiguity. > > > > struct s1 { int c; char a[(struct s2 { int c; char b[.c]; }) {.c=.c}.c]; }; > > > > Is ".c=.c" a use of the existing syntax for designated initializers, with > > the first ".c" being a designator and the second being a use of the new > > kind of expression, or is it an assignment expression, where both the LHS > > and the RHS of the assignment use the new kind of expression? And do > > those .c, when the use the new kind of expression, refer to the inner or > > outer struct definition? > > I would treat this is one integrated feature. Essentially .c is > somthing like this->c for the current struct for designated > initializer *and* size expressions because it is semantically  > so close. In the initializer I would allow only  > the current use for designated initialization for all names of > member of the currently initialized struct,  so .c = .c would  > be invalid. It should never refer to the outer struct if there I'm not clear on what the intended disambiguation rule here is, when "." is seen in initializer list context - does this rule depend on whether the following identifier is a member of the struct being initialized, so ".c=.c" would be OK above if the initialized struct didn't have a member called c but the outer struct definition did? That seems like a rather messy rule. And does "would allow only" apply other than in the ambiguous context? That seems to be implied by ".c=.c" being invalid above, because to make it invalid you need to disallow the new construct being used for the second .c, not just make the first .c interpreted as a designator. Again, this sort of thing needs a detailed written specification, with multiple iterations discussed among different implementations. The above paragraph doesn't make clear to me any of: the disambiguation rules; what is allowed in what context; how name lookup works (consider tricky cases such as a reference to an identifier declared *later* in the same struct, possibly in the context of C2x tag compatibility where a previous definition of the struct is visible); when these expressions get evaluated; what the underlying principles are behind those choices. Using a token (existing or new) other than '.' - one that doesn't introduce ambiguity in any context where expressions can be used - would help significantly, although some of the issues would still apply. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-557406811-1686932489=:41305--