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> 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 wrote: > On 08/01/2025 20:30, Tim Rentsch wrote: >> Alexis 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