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 E2828C4332F for ; Sat, 12 Nov 2022 17:02:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235034AbiKLRCl (ORCPT ); Sat, 12 Nov 2022 12:02:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231404AbiKLRCl (ORCPT ); Sat, 12 Nov 2022 12:02:41 -0500 Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DAEE15A11 for ; Sat, 12 Nov 2022 09:02:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.96,160,1665475200"; d="scan'208";a="89691037" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 12 Nov 2022 09:02:39 -0800 IronPort-SDR: pz7hoVtEetXkqRfyqpw3b5+FeJLjGnW+1ekfijIBfD+gN3pRfAcZ92/gKchzBinrEWybKhP0L5 HsZxbR+6cgD8sq7O7O3/44p+/Dvr8g7lwvN8ezQif5cP8z9LfUJOE6A4ZH8w5pbZbOoG7UPl6+ lTBIsR6fY83Efl7+r73v21agbm+dfXcrXKvpMnjAx6/O4T9QFg5n3ezc6BXpt/CpgV9rfjiskN BGtshr61W8G70TO5AT3KttCITUP6IUSeIjSiJWtNcONBys51AQIps2N0maIZu1BDVoxYUg1qhk o1s= Date: Sat, 12 Nov 2022 17:02:34 +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: <2193ac67-3b8c-b335-6e34-f7cc58062bb8@gmail.com> Message-ID: <4e8866d-ac46-e2c4-d1fa-b163d470b84e@codesourcery.com> References: <20220826210710.35237-1-alx.manpages@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> <77c3557f-4a62-3ede-4df4-4b2b78e265b1@codesourcery.com> <5ae032cd-7a5f-f72b-29ae-6ad7f418da8@codesourcery.com> <2193ac67-3b8c-b335-6e34-f7cc58062bb8@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-12.mgc.mentorg.com (139.181.222.12) 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 Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote: > > > No, assigning to a function parameter from within another parameter > > > declaration wouldn't make sense. They should be readonly. Side effects > > > should be forbidden, I think. > > > > Such assignments are already allowed. In a function definition, the side > > effects (including in size expressions for array parameters adjusted to > > pointers) take place before entry to the function body. > > Then, I'm guessing that rules need to change in a way that .initializer cannot > appear as the left operand of an assignment-expression. I think needing such a very special case rule tends to indicate that some alternative syntax, not needing such a rule, would be better. -- Joseph S. Myers joseph@codesourcery.com