From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B29BC433FE for ; Thu, 10 Nov 2022 23:20:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229559AbiKJXUC (ORCPT ); Thu, 10 Nov 2022 18:20:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbiKJXUB (ORCPT ); Thu, 10 Nov 2022 18:20:01 -0500 Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4645513DCE for ; Thu, 10 Nov 2022 15:20:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.96,155,1665475200"; d="scan'208";a="86837884" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 10 Nov 2022 15:20:00 -0800 IronPort-SDR: u/DnvJ53g2Z0c8LZJi9X8m8CeslM7y+ybmHOV6fGv7adUk3V85iYMThBNRQ2u8tGpiszoXX55T vweOtdkPu3N/P+CBCuFtrYN5unnd3rngxdB3kK8IrZcGO4dfRJ1QnnMqI5fWT6vCUxbmjqnogB tsxRsOGDUlIQmH/fSRDYvhiksZxeQObuRUTUgX/axx8eMSE5DxnVDp/wI46Jt7FbS8axuHvHuP B+OZK4oke6P/y30l7NeV5eLdtedFKsGcynEKE2B1TrzENLwXteUAWsQEPe7VaVhfDAvpHkf3Yd Lio= Date: Thu, 10 Nov 2022 23:19:54 +0000 From: Joseph Myers To: Martin Uecker CC: Alejandro Colomar , Ingo Schwarze , JeanHeyd Meneide , , Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters In-Reply-To: Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-15.mgc.mentorg.com (139.181.222.15) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org 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". 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. (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.) -- Joseph S. Myers joseph@codesourcery.com