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 449473858039 for ; Sat, 12 Nov 2022 13:03:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 449473858039 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.96,159,1665475200"; d="scan'208";a="89683343" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 12 Nov 2022 05:03:33 -0800 IronPort-SDR: DBmus25gbQ9wLnON5Z0nWpbCyP3Xj6Bj5rBBqWMkSp9Xy8ZPnPJWPFMOhfu2smKxyG4yShGfK8 btlDq03oBI68Awi1+y1hUclFeCRMLRDHFaznCrZuwXBz0inA7bM2Kq9ZZUYBnCS9E+xUawLAs2 g6VkWJBbjrxVZ8neAyunLC/qRahHBBUmFZf7kAcFluMsp3iadA3b26G4zeN+13evEasaKWoCCf SOf1boIZbAqzuqcOND2abgTbG6AiTGyeWA9y+Wg8YD4cdjCFeJ3max4CBAb7FpGM5LyBkgNXJ7 AyU= Date: Sat, 12 Nov 2022 13:03:27 +0000 From: Joseph Myers To: Alejandro Colomar CC: Martin Uecker , Ingo Schwarze , JeanHeyd Meneide , , Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters In-Reply-To: <68746776-87bf-80f9-8e3e-7392e8cef1bb@gmail.com> Message-ID: <77c3557f-4a62-3ede-4df4-4b2b78e265b1@codesourcery.com> References: <20220826210710.35237-1-alx.manpages@gmail.com> <5ba53bad-019e-8a94-d61e-85b2f13223a9@gmail.com> <491a930d-47eb-7c86-c0c4-25eef4ac0be0@gmail.com> <2abccaa2-d472-4c5b-aea6-7a2dddd665da@gmail.com> <4475b350c2a4d60da540c0f3055f466640e6c409.camel@tugraz.at> <51f5a2f2-84c1-bc75-cf94-0cdc1771d37f@gmail.com> <4e3fee795769544738b3dc793aa95d6b34b72047.camel@tugraz.at> <69d694b3-756-792d-8880-87bab482ea34@codesourcery.com> <76c083af-c01f-a4b2-3df-c83075c6b0de@codesourcery.com> <75c352c-e8b5-90d0-5fae-7b211c647934@codesourcery.com> <68746776-87bf-80f9-8e3e-7392e8cef1bb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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=-3110.0 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP 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: On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote: > > struct s { int a; }; > > void f(int a, int b[((struct s) { .a = 1 }).a]); > > Is it really ambiguous? Let's show some currently-valid code: Well, I still don't know what the syntax addition you propose is. Is it postfix-expression : . identifier (with a special rule about how the identifier is interpreted, different from the normal scope rules)? If so, then ".a = 1" could either match assignment-expression directly (assigning to the postfix-expression ".a"). Or it could match designation[opt] initializer, where ".a" is a designator. And as I've noted many times in discussions of C2x proposals on the WG14 reflector, if some sequence of tokens can match the syntax in more than one way, there always needs to be explicit normative text to disambiguate the intended parse - it's not enough that one parse might lead later to a violation of some other constraint (not that either parse leads to a constraint violation in this case). Or is the syntax array-declarator : direct-declarator [ . assignment-expression ] (with appropriate variants with static and type-qualifier-list and for array-abstract-declarator as well, and with different identifier interpretation rules inside the assignment-expression)? If so, then there are big problems parsing [ . ( a ) + ( b ) ], where 'a' is a typedef name in an outer scope, because the appropriate parse would depend on whether 'a' is shadowed by a parameter - unless of course you add appropriate wording like that present in some places about not being able to use this syntax to shadow a typedef name. Or is it just array-declarator : direct-declarator [ . identifier ] which might avoid some of these problems at the expense of being less expressive? If you're proposing a C syntax addition, you always need to be clear about exactly what the new cases in the syntax would be, and how you resolve ambiguities with any other existing part of the syntax, how you interact with rules on scopes, namespaces and linkage of identifiers, etc. -- Joseph S. Myers joseph@codesourcery.com