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 E9E843858D1E for ; Fri, 11 Nov 2022 19:52:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E9E843858D1E 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 [192.168.0.150] (84-115-221-90.cable.dynamic.surfer.at [84.115.221.90]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4N88VY4QxKz1LB1y; Fri, 11 Nov 2022 20:52:05 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4N88VY4QxKz1LB1y DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1668196327; bh=us0QboMBDFu9aHTIQqc0TrvZGpnMDJEB406Ps+h2NJY=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=KGeOQFVIBUpmX68ZijrL+J8OqwfaMfvdOLjCfpnLpT1jJkz0DQTobLb32VPM7nS7Q xVny+OLu4MJPa8hPPdr2jI8ypszsTLMDf9xi5LuURH+r4fw5UM/WZPuT6lxnF+v1rh NxaJZsWp99i14C7YSPheytc63/FAF0xmPkZb87BQ= Message-ID: Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters From: Martin Uecker To: Joseph Myers Cc: Alejandro Colomar , Ingo Schwarze , JeanHeyd Meneide , linux-man@vger.kernel.org, gcc@gcc.gnu.org Date: Fri, 11 Nov 2022 20:52:04 +0100 In-Reply-To: <75c352c-e8b5-90d0-5fae-7b211c647934@codesourcery.com> References: <20220826210710.35237-1-alx.manpages@gmail.com> <89d79095-d1cd-ab2b-00e4-caa31126751e@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> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP 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, den 10.11.2022, 23:19 +0000 schrieb Joseph Myers: > On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote: > > > One problem with WG14 papers is that people put in too much, > > because the overhead is so high and the standard is not updated > > very often. It would be better to build such feature more > > incrementally, which could be done more easily with a compiler > > extension. One could start supporting just [.x] but not more > > complicated expressions. > > Even a compiler extension requires the level of detail of specification > that you get with a WG14 paper (and the level of work on finding bugs in > that specification), to avoid the problem we've had before with too many > features added in GCC 2.x days where a poorly defined feature is "whatever > the compiler accepts". I think the effort needed to specify the feature correctly can be minimized by making the first version of the feature as simple as possible. > If you use .x as the notation but don't limit it to [.x], you have a > completely new ambiguity between ordinary identifiers and member names > > struct s { int a; }; > void f(int a, int b[((struct s) { .a = 1 }).a]); > > where it's newly ambiguous whether ".a = 1" is an assignment to the > expression ".a" or a use of a designated initializer. If we only allowed [ . a ] then this example would not be allowed. If need more flexibility, we could incrementally extend it. > (I think that if you add any syntax for this, GNU VLA forward declarations > are clearly to be preferred to inventing something new like [.x] which > introduces its own problems.) I also prefer this. I proposed forward declarations but WG14 and also people in this discussion did not like them. If we would actually start using them, we could propose them again for the next revision. Martin