From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 629863858D35 for ; Fri, 16 Jun 2023 17:07:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 629863858D35 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at Received: from vra-172-180.tugraz.at (vra-172-180.tugraz.at [129.27.172.180]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4QjQZf25TCz3wVN; Fri, 16 Jun 2023 19:07:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1686935259; bh=EtCu+fBx2WMviuLeH6S1euxycXaT/Y5kNi00owf++0c=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=gzuKwPDbgQ4ZGKJf5Mq6HkzG9jSujXPm6vDb86ZM3quXnBqaryOuKmTQVZDq8T2ln zPzhSzNZ1uQ49bEMiClvkNQHuUJWSmLNRxiTSdEPxEAqcaaX+IPtkkPih3c1+ESwR8 i5AP2PIMkwpj1eFyFv/2cMc/2+ZYZ7WdYxMvnnUI= Message-ID: Subject: Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896) From: Martin Uecker To: Joseph Myers Cc: Qing Zhao , Qing Zhao via Gcc-patches , "richard.guenther@gmail.com" , "jakub@redhat.com" , "keescook@chromium.org" , "siddhesh@gotplt.org" , "isanbard@gmail.com" Date: Fri, 16 Jun 2023 19:07:37 +0200 In-Reply-To: <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> <6068bad0-a0c4-3f41-6640-9d3b062794f@codesourcery.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Am Freitag, dem 16.06.2023 um 16:21 +0000 schrieb Joseph Myers: > 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?  When initializers are parsed it is already clear what the names of the members of the inner struct are, so one can differentiate between designated initializers  and potential other uses in an expression.  So the main rule is: if you parse .something in a context where a designator is allowed and "something" is a member of the current struct, then it is a designator. So for struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; }; one knows during parsing that the .d is a designator and that .c is not. For struct foo { int c; int buf[(struct { int d; }){ .c = .c }]; }; one knows that both uses of .c are not. Whether these different use cases should be allowed or not is a different question, but my point is that there does not seem to be a problem directly identifying the uses  as a designator as usual. To me, this seems to imply that it is safe to use the same syntax. > 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. Yes. > > Again, this sort of thing needs a detailed written specification, with > multiple iterations discussed among different implementations.  Oh, I agree with this. > 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. I also agree that all this needs careful consideration and written rules. My point is mereley that there does not seem to be a fundamental issue differentiating the new feature from  designators during parsing, so there may not be a risk using  the same syntax. > 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. The cost of using a new symbol is that one has two different syntax for something which is semantically equivalent, i.e. a notion to refer to a member of the current struct. Martin >