From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from iguana.tulip.relay.mailchannels.net (iguana.tulip.relay.mailchannels.net [23.83.218.253]) by sourceware.org (Postfix) with ESMTPS id 26A06385828B for ; Mon, 4 Dec 2023 20:35:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 26A06385828B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=tempfail smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 26A06385828B Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.218.253 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701722122; cv=pass; b=Bz903ZIkQ7ljTA3g7Ft9H0gzZgzO2P8UKmsFFBmxDOzIYmZyq0mgCdccrpogyg96VyABKTG48jMI0NA+ZLEA8y54n05nKje+SjvtZdW6ROeYuX9S+HA3ZN0m4mMe91+60bpfjWAocvX+PILQbVCqjGpCuSrZchpqCuV2r+tMXgA= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701722122; c=relaxed/simple; bh=nIUQXIkQ0BS1eoOSq0ISGCYXJkkDEUB85rild3jQ5pQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=B3Czn97z2prXZ8lyhmtGb/FnWbe7kufWJM2s0lhaRwfg4PJSV6jMdk0WGr1R6109Y/DL34g2OsS68BQP/7s+eJx6/y0qhXAysM/5+hir/K1OG+mk6PtJR16qc35+bT0odIsceIkWgKTRBtVLrbMO18flIO/7yjva4t+FoNtXId4= ARC-Authentication-Results: i=2; server2.sourceware.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 64C6541F9B; Mon, 4 Dec 2023 20:35:09 +0000 (UTC) Received: from pdx1-sub0-mail-a253.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EE56A41ED9; Mon, 4 Dec 2023 20:35:08 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1701722109; a=rsa-sha256; cv=none; b=SvSWXppOxTrZDdhYFUgbaecLo/m8BQOvNAMQbblZBFc7w5AJDjt2kMdA6CYS0rfbzJOYlH ExG2Wsn0pne/cvb99foCKNB03bWTMVkhultb9OUZuuUps/TWL6LaTQm2TXfHqyGwL9asS8 VmjswtdUaYcUxO6frGXOmvrDx2J5EuqiuJ2bxWIL8kHUTV4h9vR1QC80STaoKFnhZ1nfJW zwwh76+pOer/jZhvmZFzRjdUjH+Li9Zu7mpjNjVj3PEBDMmrpflJjyzZVwRqbAMScj3j70 7xY/gOsKjje5KqMSp/9hIPJFQ3w2+XYOq+XiryrsZPPEATr8G1slXK+VoQQEzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1701722109; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1YZOYEos6JgNTWPoMPgM8hhnoYQuNoeVE0rwTNLzSco=; b=tfneB/SXzqOAAlImgQSDtZouwqUKnRXIaai8CCAYinHvByExbY7OIVjSkFgty5W639ZkcO QYYoegJYxiKXd7K/X8XNOHoOPMHct4m9w0dqLa9svbZeDu40I7sIAs2CrdFmM5k9i1ZMou pg3GuLZF2XUKdQAJCUV1BvqtaMTxWxYB/hgfOMmpGm6lL1IAgkbR7ki/GizPqvC5M5zsuq 6kit24khpRbCPzpnL2fL/CSSIAkTGQS4p0MQlHOnE1m9ltJNDr5Pl246Jth7bthEDl5IUc wmQub/t6MqaB1tDnoB4OzHFEkSRtwyc7VeJffY4gPSCiT8w9aNQKeatXFtH0AQ== ARC-Authentication-Results: i=1; rspamd-696ff67dc8-w8qvj; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Abaft-Little: 1f47d5c705db076c_1701722109216_1763021239 X-MC-Loop-Signature: 1701722109216:1432992793 X-MC-Ingress-Time: 1701722109216 Received: from pdx1-sub0-mail-a253.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.126.216.6 (trex/6.9.2); Mon, 04 Dec 2023 20:35:09 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-136.dsl.bell.ca [142.113.138.136]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a253.dreamhost.com (Postfix) with ESMTPSA id 4Skb583NfMz2s; Mon, 4 Dec 2023 12:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1701722108; bh=1YZOYEos6JgNTWPoMPgM8hhnoYQuNoeVE0rwTNLzSco=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=MMw1MChHcTEjfbrO+eHg3XsIlvK8k3ZHJr9FtXM35qiL3pvU5f7kX/mlnV2/mgsyx dYJ+GlJ5KCXm/tQu3dojj3yemBfeXspvT96wlbh2A0oqZcx8M1NEEUVRO4j8DVYn5Y Zks0hs+2gIOuPji1+EpjjFsgLjAi6uFbaGpANa2tOewhNeaZSgXl57w1zD9Ca/a0yg o6Dpdf9Xr3p5ROr/SqbeG+x3wSYVhkZGSNGYkrvTRLIS0ah73yHiKjqALtbKQ5tt3a zj+lrC4SuGXooiAzDmokZCWntn19rohX0jfjXKuKqjChFgEsgJjvHFAx6tLsvsyvz6 RGUzKN78t/NeA== Message-ID: <81ebaa59-ada2-4ba4-b03e-5f7247b2fe5b@gotplt.org> Date: Mon, 4 Dec 2023 15:35:07 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [gcc15] nested functions in C Content-Language: en-US To: Martin Uecker , Andreas Schwab Cc: polacek@redhat.com, gcc-patches@gcc.gnu.org References: <7862c488-5afd-4018-9dc5-c72d9382a052@gotplt.org> <48690099bc3fb6030191d2c58525fcfc415da107.camel@tugraz.at> <3b959c8a-0a65-4185-a943-122bb898796f@gotplt.org> <90f24d27f63622b90166f43a3648e41c7c911c90.camel@tugraz.at> From: Siddhesh Poyarekar In-Reply-To: <90f24d27f63622b90166f43a3648e41c7c911c90.camel@tugraz.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3488.5 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,KAM_DMARC_STATUS,NO_DNS_FOR_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_TEMPERROR 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 2023-12-04 13:48, Martin Uecker wrote: >> I empathize with Jakub's stated use case though of keeping the C >> frontend support for testing purposes, but that could easily be done >> behind a flag, or by putting nested C func deprecation behind a flag. > > I am relatively sure C will get some form of nested functions. > Maybe as anonymous nested functions, i.e. lambdas, but I do > not see a fundamental difference here (I personally like naming > things for clarity, so i prefer named nested functions) If (assuming from them being called lambdas) they are primarily for small functions without side-effects then it's already a significantly stronger specification than what we have right now with C nested functions. That would end up enforcing what you demonstrate as the good way to use nested functions. I suppose minimal, contained side-effects (such as atomically updating a structure) may also constitute sound design, but that should be made explicit in the language. >> I don't disagree for cases like -Warray-bounds, >> but for warnings/errors that are more deterministic in nature (like >> -Werror=trampolines), they're going to point at actual problems and >> larger projects and distributions will usually prefer to at least track >> them, if not actually fix them. For Fedora we tend to provide macro >> overrides for packages that need to explicitly disable a security >> related flag. > > In projects such as mine, this will lead to a lot of code > transformations as indicated above, i.e. much worse code. > > One could get away with it, since nested functions are rarely > used, but I think this is bad, because a lot of code would > improve if it used them. If nested functions are eventually going to make it into the C standard then effort is probably better spent in porting the C nested functions to use descriptors instead of executable stacks or heaps. Thanks, Sid