Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Kaz Kylheku <643-408-1753@kylheku.com>
Newsgroups: comp.lang.c
Subject: Re: Opinions on `defer`?
Date: Thu, 9 Jan 2025 19:40:23 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 80
Message-ID: <20250109105742.846@kylheku.com>
References: <87y0znpik1.fsf@gmail.com> <86sept85nz.fsf@linuxsc.com>
 <vlohbs$3bs33$3@dont-email.me>
Injection-Date: Thu, 09 Jan 2025 20:40:23 +0100 (CET)
Injection-Info: dont-email.me; posting-host="701316071098cc7b6fe8181daaf2e5b8";
	logging-data="3695282"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19SRc5zj7pOrwsjsZCjTf8IPqi+O8y+Drs="
User-Agent: slrn/pre1.0.4-9 (Linux)
Cancel-Lock: sha1:r0u4MIGf5nuyeJE48kxXydHHKac=
Bytes: 4567

On 2025-01-09, David Brown <david.brown@hesbynett.no> wrote:
> On 08/01/2025 20:30, Tim Rentsch wrote:
>> Alexis <flexibeast@gmail.com> writes:
>> 
>>> Hi all,
>>>
>>> "Modern C" author Jens Gustedt has been posting on his blog about a
>>> proposed `defer` feature (as provided by e.g. Zig and Go), the most
>>> recent being:
>>>
>>>    https://gustedt.wordpress.com/2025/01/06/simple-defer-ready-to-use/
>>>
>>> What do people here think about having such a feature in C?
>> 
>> The issue being addressed is one well worth addressing.
>> 
>> The proposed solution ('defer') is awful.  If this feature is
>> being considered for the C standard it should be rejected
>> out of hand.
>
> Jens Gustedt is not just some random C programmer - or even just some 
> random C book author.  He is an active member of the C standards 
> committee, AFAIUI.
>
> You might not agree with his suggested feature, and perhaps the rest of 
> the C standards committee will reject it - that's why there is a 
> committee, so that different ideas and suggestions can be discussed and 
> considered from different viewpoints.
>
> But his suggestion should /not/ be rejected out of hand.  The guy has 
> the qualifications, and done the work, to have the right to be given 

He has written a few macros relying on GCC features, where the real work
has been done.

That underlying GCC features is what should be standardized, if anything,
and not the proposed defer syntax:

- nested functions which have access to the parent lexicals
- the cleanup feature
- the __COUNTER__ preprocessor feature

All of these are beyond proof-of-concept, but used in production. It is
years old and mature.

What we don't want is ISO C to be reinventing any more GCC extensions,
in a different way. There is an annoying history of that.
(It's bad enough when committees just invent stuff that hasn't been
implemented anywhere, but it's almost an insult when they ignore what
has been implemented and invent something incompatible.)

Note: the nested, local functions used in the presented solution are not
being used as downward funargs (functional arguments): i.e.  passed down
to callee functions for indirect calling. The cleanup calls take place
in the parent function frame.  Thus for the purposes of these defer
macros, we don't need to specify a full blown nested function that
supports downward funargs. The standard could say that if the address
of a local function is communicated outside of the function scope where
it was taken, its value is indeterminate. Then the downard funarg
support becomes a GNU extension.

Supporting downward funargs is not a mere difficulty. The solution
chosen in GCC for local access (trampolines) has security implications:
a program which uses local functions (such as one relying on these defer
macros) requires an executable stack: the virtual memory pages of its
stack segment allow code execution. This is because pointers to local
functions are aimed at small pieces of dynamically generated machine
code, allocated on the stack, called trampolines. A trampoline is
co-located with the environment pointer needed by the closure; its tiny
machine code sequence loads the environment pointer relative to the
program counter, and then calls the real function (which is not stack
allocated). Thus, a function-with-environment which would normally
require two pointer-sized words of storage can be represented by a
simple function pointer.


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca