Re: Opinions on `defer`?

On 09/01/2025 20:40, Kaz Kylheku wrote:

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.
 

Yes, standardising these would be a good thing for C IMHO.  (I seem to recall __COUNTER__ being standardised, but I'm not sure on that.)  I believe Jens Gustedt has also proposed a form of lambdas for C - that would work as an alternative to gcc's nested functions.
However such local functions end up if and when they get standardised, I think it is not unreasonable if there are restrictions that block any usage that requires passing around data in addition to the function. That is to say, you should not be able to pass on a pointer to a local function that has captures - anything that needs a gcc nested function "trampoline" or a C++ lambda style function object should not be allowed.  That would still leave full flexibility for local use of local functions - such as used here for the "defer" macros - as well as supporting convenient local functions for things like qsort comparison functions.

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.

Sometimes they do need to make some modifications to gcc extensions - but it is nice when they don't need to.

(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.)

I don't think they now accept any serious change that hasn't been tested in a real implementation.

 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.

Agreed (though I'd also be happy to accept passing on a local function's address if it is self-contained and does not access any captures).
(I should have read the rest of your post before writing much the same thing a few paragraphs up, as it covers much the same thing.)

 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.