Re: [gcc15] nested functions in C

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

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

If (assuming from them being called lambdas) they are primarily for 
small functions without side-effects then it's already a significantly 
stronger specification than what we have right now with C nested 
functions.  That would end up enforcing what you demonstrate as the good 
way to use nested functions.

I suppose minimal, contained side-effects (such as atomically updating a 
structure) may also constitute sound design, but that should be made 
explicit in the language.

>> I don't disagree for cases like -Warray-bounds,
>> but for warnings/errors that are more deterministic in nature (like
>> -Werror=trampolines), they're going to point at actual problems and
>> larger projects and distributions will usually prefer to at least track
>> 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.
> 
> In projects such as mine, this will lead to a lot of code
> transformations as indicated above, i.e. much worse code.
> 
> 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.

If nested functions are eventually going to make it into the C standard 
then effort is probably better spent in porting the C nested functions 
to use descriptors instead of executable stacks or heaps.

Thanks,
Sid