Re: Opinions on `defer`?

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