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 6EABB385B528 for ; Mon, 4 Dec 2023 21:31:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6EABB385B528 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6EABB385B528 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701725517; cv=none; b=OeLMN5PU2YYzN1Q8jclX5L3KtQXYXcHRJlaHQqXyDzyP+3Hxmchb2IVWsbK8PbSCz/Wh58YQ6bLSiuyuAjB3t7pud4in8QuuaSc7Whr2NJvY31U9rF/Z9BBRw1vFLRL3u2Q9QVKkK44c/JMr2FT0WlWK662I9s9KyC7zcznqJmw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701725517; c=relaxed/simple; bh=XRTpKLYT0k871ANpECOyC6jP8TiS9+GNxAf9JXG23LI=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=fdLNcXHXhqQGwKNq95tQEHVYZBGn28JSVr895CN6Z2/eAZ7dlB4bsTBHRnkaD5Z2HXfM7bKVLdttY4Wvn2jscnAz+ZH8hwJPfHwFChOCyMWqTVO2cBbU9dg+H8wbW1bEipCi0HTd/Y0aLnWlDErSufoGgHLmJ1AvjQd9AhK8yJM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-168-61.tugraz.at (vra-168-61.tugraz.at [129.27.168.61]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SkcLD0Mglz1LM05; Mon, 4 Dec 2023 22:31:31 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 mailrelay.tugraz.at 4SkcLD0Mglz1LM05 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1701725492; bh=pmSDF1i6U9chGNahXyRiudairVVx7hioM7MGRuEcnJk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=V74hNK2HApQC3rvRXw4GuyaLcxjg9X/OsGW6FGgtPnUqVwsS0W7JoILyZ9sAkVsfq 9aJCYeUbFyd/6xAMUkVenkBRtroH+YsbGtSuPPDaHlBA/WFHAkgcjcZdsuudbI2GGF 9aTju9KpBoMXrPldWphuPTrt9MuXXFVJX0A+WUqA= Message-ID: <30bf8bb5c7fa08344c39b23e4249d7df69f2bb26.camel@tugraz.at> Subject: Re: [gcc15] nested functions in C From: Martin Uecker To: Siddhesh Poyarekar , Andreas Schwab Cc: polacek@redhat.com, gcc-patches@gcc.gnu.org Date: Mon, 04 Dec 2023 22:31:31 +0100 In-Reply-To: <81ebaa59-ada2-4ba4-b03e-5f7247b2fe5b@gotplt.org> References: <7862c488-5afd-4018-9dc5-c72d9382a052@gotplt.org> <48690099bc3fb6030191d2c58525fcfc415da107.camel@tugraz.at> <3b959c8a-0a65-4185-a943-122bb898796f@gotplt.org> <90f24d27f63622b90166f43a3648e41c7c911c90.camel@tugraz.at> <81ebaa59-ada2-4ba4-b03e-5f7247b2fe5b@gotplt.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 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.116 X-Spam-Status: No, score=-4.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,T_SCC_BODY_TEXT_LINE 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 Montag, dem 04.12.2023 um 15:35 -0500 schrieb Siddhesh Poyarekar: > 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. > >=20 > > 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) >=20 > If (assuming from them being called lambdas) they are primarily for=20 > small functions without side-effects then it's already a significantly= =20 > stronger specification than what we have right now with C nested=20 > functions. That would end up enforcing what you demonstrate as the good= =20 > way to use nested functions. The proposal we have seen for C23 (which was not accepted into C23 mostly due to timing and lack of implementation experience) were similar to C++'s lambdas and did not have any such restriction. >=20 > I suppose minimal, contained side-effects (such as atomically updating a= =20 > structure) may also constitute sound design, but that should be made=20 > explicit in the language. Updating some variable is useful for example for contractions, e.g. summing over a certain range of values in an array, etc. >=20 > > > I don't disagree for cases like -Warray-bounds, > > > but for warnings/errors that are more deterministic in nature (like > > > -Werror=3Dtrampolines), they're going to point at actual problems and > > > larger projects and distributions will usually prefer to at least tra= ck > > > 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. > >=20 > > In projects such as mine, this will lead to a lot of code > > transformations as indicated above, i.e. much worse code. > >=20 > > 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. >=20 > If nested functions are eventually going to make it into the C standard= =20 > then effort is probably better spent in porting the C nested functions= =20 > to use descriptors instead of executable stacks or heaps. I submitted a patch for this a long time ago which was based on the code for Ada that uses a bit in the pointer to differentiate between conventional pointers and descriptors. I would now prefer an approach that uses a qualifier on the function type to indicate that the static chain has to be set. A pointer to such a qualified function would a descriptor that consists of the address and the value for the static chain. This would be useful for many things. Martin