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 C9052385701B for ; Fri, 16 Jun 2023 07:21:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C9052385701B 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 4Qj9Yw2D6rz3wHl; Fri, 16 Jun 2023 09:21:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1686900069; bh=fNx7nHnR7o30vK3TzxTK2GA8mpK8WG+8F6EBhqU6V+U=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=c9p5liILzXnBLXkjrmfT4xIYxZqY5KYuEytXx0bZV3V+npM1grazmuuGvNMJQl/08 nLVJU83G6zfh/T/3AS3aakKSVhNqzPYy2FP7RLfZv20n65WubIxwUWZ/VUyjDjNTTx 7ioJn/p8luzIn2qQDR0zbRBkyKhfyLWJbIZ4QWE0= Message-ID: Subject: Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896) From: Martin Uecker To: Joseph Myers , Qing Zhao Cc: 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 09:21:07 +0200 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1+deb11u1 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.116 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 Donnerstag, dem 15.06.2023 um 16:55 +0000 schrieb Joseph Myers: > On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote: > ... > > 1. Update the routine “c_parser_postfix_expression” (is this the right > > place? ) to accept the new designator syntax. > > Any design that might work with an expression is the sort of thing that > would likely involve many iterations on the specification (i.e. proposed > wording changes to the C standard) for the interpretation of the new kinds > of expressions, including how to resolve syntactic ambiguities and how > name lookup works, before it could be considered ready to implement, and > then a lot more work on the specification based on implementation > experience. > > 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 is a member with the same name in the inner struct, i.e. the outside member is then hidden. So this would be ok: struct s1 { int d; char a[(struct s2 { int c; char b[.c]; }) {.c=.d}.c]; }; Here the use of .d would be ok because it is not from the struct currently initialized, but from an outside scope. Martin