From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 247AA3858D1E for ; Tue, 29 Nov 2022 15:44:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 247AA3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id E906521AB0; Tue, 29 Nov 2022 15:44:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669736642; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1dpLe3l6q28ZdHJTn0N3XxXZRnyoO/cfX9dnRjUoirs=; b=dsxnQFKH/Mgafyygy8SWjitys6bNnTQqwIqTaETLlYn1zF5IeuX08JQILLK/S3CTcWEikY L4Ni5CageiVn7NJlpS/8tloXU2UuQg/h4SbxXozjNzPP5TBciub81ykZ/nkn2zlpkBk3H+ UQ4orO3AGjno608JLoxSWdKZFDSxMtM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669736642; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1dpLe3l6q28ZdHJTn0N3XxXZRnyoO/cfX9dnRjUoirs=; b=0xqnxnRPlvfI1DH+j3yzhpXHzH2n3jPpsens6FFkSLXr4Lv6hZ3nw5fx5hIFhM0NZ/yfJb sdkObjmcCEhmzaBg== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C8FE02C142; Tue, 29 Nov 2022 15:44:02 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id B7A1C65E6; Tue, 29 Nov 2022 15:44:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id B4A1065E2; Tue, 29 Nov 2022 15:44:02 +0000 (UTC) Date: Tue, 29 Nov 2022 15:44:02 +0000 (UTC) From: Michael Matz To: "Uecker, Martin" cc: "alx.manpages@gmail.com" , "gcc@gcc.gnu.org" , "linux-man@vger.kernel.org" , "joseph@codesourcery.com" , "schwarze@usta.de" , "wg14@soasis.org" Subject: Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters In-Reply-To: <5ccbf8ed11bd542477980f58aa277bf4335f1281.camel@med.uni-goettingen.de> Message-ID: References: <20220826210710.35237-1-alx.manpages@gmail.com> <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> <7931044a-b707-5a70-86c2-be298c35aa57@gmail.com> <792055f0-114d-d4bc-52f0-c242d1767c0b@gmail.com> <31e1cf34-b42f-24c5-2109-f8214c28af3e@gmail.com> <494309ce-c8ec-5219-f83e-b8dda5b9bcd1@gmail.com> <5ccbf8ed11bd542477980f58aa277bf4335f1281.camel@med.uni-goettingen.de> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609957120-1909256762-1669736642=:24878" X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-1909256762-1669736642=:24878 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Hey, On Tue, 29 Nov 2022, Uecker, Martin wrote: > It does not require any changes on how arrays are represented. > > As part of VM-types the size becomes part of the type and this > can be used for static or dynamic analysis, e.g. you can  > - today - get a run-time bounds violation with the sanitizer: > > void foo(int n, char (*buf)[n]) > { > (*buf)[n] = 1; > } This can already statically analyzed as being wrong, no need for dynamic checking. What I mean is the checking of the claimed contract. Above you assure for the function body that buf has n elements. This is also a pre-condition for calling this function and _that_ can't be checked in all cases because: void foo (int n, char (*buf)[n]) { (*buf)[n-1] = 1; } void callfoo(char * buf) { foo(10, buf); } buf doesn't have a known size. And a pre-condition that can't be checked is no pre-condition at all, as only then it can become a guarantee for the body. The compiler has no choice than to trust the user that the pre-condition for calling foo is fulfilled. I can see how being able to just check half of the contract might be useful, but if it doesn't give full checking then any proposal for syntax should be even more obviously orthogonal than the current one. > For > > void foo(int n, char buf[n]); > > it semantically has no meaning according to the C standard, > but a compiler could still warn. Hmm? Warn about what in this decl? > It could also warn for > > void foo(int n, char buf[n]); > > int main() > { > char buf[9]; > foo(buf); > } You mean if you write 'foo(10,buf)' (the above, as is, is simply a syntax error for non-matching number of args). Or was it a mispaste and you mean the one from the godbolt link, i.e.: void foo(char buf[10]){ buf[9] = 1; } int main() { char buf[9]; foo(buf); } ? If so, yeah, we warn already. I don't think this is an argument for (or against) introducing new syntax. ... > But in general: This feature is useful not only for documentation > but also for analysis. Which feature we're talking about now? The ones you used all work today, as you demonstrated. I thought we would be talking about that ".whatever" syntax to refer to arbitrary parameters, even following ones? I think a disrupting syntax change like that should have a higher bar than "in some cases, depending on circumstance, we might even be able to warn". Ciao, Michael. ---1609957120-1909256762-1669736642=:24878--