From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id BF41E385B800 for ; Mon, 14 Nov 2022 18:13:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BF41E385B800 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,164,1665475200"; d="scan'208";a="87092281" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 14 Nov 2022 10:13:18 -0800 IronPort-SDR: CksuF99aYULDFL0SPSPLNLz+udvtf+xF2QvscV5/sdXWiC1/j8GQZ545N9GYxNId3SxSl6O/LM SBtkstzJwgUyKjVuhgsp0yTgzQcKJUaCAwTbY1Idp0zaktRo6Xww0k7j2SFL2rcB9l0denUg6B JBp2ciOrxRanJuBsfvvf9FmS+LSkl2RVS4FZ8zXPTohZdOgWRsWsBNTYbmdRk8DwoegSF1GYbL 9u2DDFNO86qS+vguCsyHFLeLqXHW/bc8qZ1KRzaUiSyUs/mdUuxFkLT7j5rR3NKvjoAbV+OHvV 7TI= Date: Mon, 14 Nov 2022 18:13:13 +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: <9560a2e4-0234-d07e-2d7a-302015318771@gmail.com> Message-ID: References: <20220826210710.35237-1-alx.manpages@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> <77c3557f-4a62-3ede-4df4-4b2b78e265b1@codesourcery.com> <5ae032cd-7a5f-f72b-29ae-6ad7f418da8@codesourcery.com> <7931044a-b707-5a70-86c2-be298c35aa57@gmail.com> <792055f0-114d-d4bc-52f0-c242d1767c0b@gmail.com> <31e1cf34-b42f-24c5-2109-f8214c28af3e@gmail.com> <85bc60c2-c9b2-7998-1722-4201932d3a91@gmail.com> <9560a2e4-0234-d07e-2d7a-302015318771@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-14.mgc.mentorg.com (139.181.222.14) 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,RCVD_IN_MSPIKE_H2,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 Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote: > SYNOPSIS: > > unary-operator: . identifier That's not what you mean. See the standard syntax. unary-expression: [other alternatives] unary-operator cast-expression unary-operator: one of & * + - ~ ! > - It is not an lvalue. > > - This means sizeof() and _Lengthof() cannot be applied to them. sizeof can be applied to non-lvalues. > - This prevents ambiguity with a designator in an initializer-list within > a nested braced-initializer. No, it doesn't. See my previous points about syntactic disambiguation being a separate matter from "one parse would result in a constraint violation, so choose another parse that doesn't" (necessarily, because the constraint violation that results could in general be at an arbitrary distance from the point where a choice of parse has to be made). Or see e.g. the disambiguation rule about enum type specifiers: there is an explicit rule "If an enum type specifier is present, then the longest possible sequence of tokens that can be interpreted as a specifier qualifier list is interpreted as part of the enum type specifier." that ensures that "enum e : long int;" interprets "long int" as the enum type specifier, rather than "long" as the enum type specifier and "int" as another type specifier in the sequence of declaration specifiers, even though the latter parse would result in a constraint violation later. Also, requiring unbounded lookahead to determine what kind of construct is being parsed may be considered questionable for C. (If you have an initializer starting .a.b.c.d.e, possibly with array element access as well, those could all be designators or .a might be a reference to a parameter of struct or union type and .b.c.d.e a sequence of references to members within it and disambiguation under your rule would depend on whether an '=' follows such an unbounded sequence.) > - The type of a .identifier is always an incomplete type. > > - This prevents circular dependencies involving sizeof() or _Lengthof(). We have typeof as well, which can be applied to expressions with incomplete type. > - Shadowing rules apply. > > - This prevents ambiguity. "Shadowing rules apply" isn't much of a specification. You need detailed wording that would be added to 6.2.1 Scopes of identifiers (or equivalent elsewhere) to make it clear exactly what scopes apply for identifiers looked up using this construct. > - > void foo(struct bar { int x; char c[.x] } a, int x); > > Explanation: > - Because of shadowing rules, [.x] refers to the struct member. I really don't think standardizing VLAs-in-structures would be a good idea. Certainly it would be a massive pain to specify meaningful semantics for them and this outline doesn't even attempt to work through the consequences of removing the rule that "If an identifier is declared as having a variably modified type, it shall be an ordinary identifier (as defined in 6.2.3), have no linkage, and have either block scope or function prototype scope.". The idea that .x as an expression might refer to either a member or a parameter is also a massive change to the namespace rules, where at present those are in completely different namespaces and so in any given context a name only needs looking up as one or the other. Again, proposals should be *minimal*. And even when they are, many issues may well arise in practice (see the long list of constexpr issues in my commit message for that C2x feature, for example, which I expect to turn into multiple NB comments and at least two accompanying documents). -- Joseph S. Myers joseph@codesourcery.com