IRC channel logs
2026-02-07.log
back to list of logs
<johnwcowan>old: thats how nested functions work in Algol and Pascal <lilyp>are GNU C's nested functions actually evaluated at compile time? <old>I guess that's how I would implement "closure" with guile-steel <lilyp>because if not, I have some bad news for you <johnwcowan>not sure what you mean by "evaluated" : are ordinary C functiins evaluated? <mwette>lilyp: The code for the nested function has access to the same frame pointer that the parent has, so access to all the parents locals. No biggie. But like old said, I'm guessing taking the address of a nested function is an error. <lilyp>johnwcowan: ahh, yes, I was being confusing there; what I mean is whether the codegen actually writes out the entire function at compile time <lilyp>last time I checked – which is the root cause for the UB mwette is hinting at – nested functions were actually deferred to runtime (at least in part), meaning you won't have W^X protection for your stack <lilyp>which is very bad if you happen to like gets :) <johnwcowan>no, yoy can take its address, which is the address of a trampoline allocated on the heap. you can't call it when the scope has exited <johnwcowan>"If you try to call the nested function through its address after the containing function exits, all hell breaks loose. If you try to call it after a containing scope level exits, and if it refers to some of the variables that are no longer in scope, you may be lucky, but it’s not wise to take the risk. If, however, the nested function does not refer to anything that has gone out of scope, you <johnwcowan>you can also do non-local gotos into outer scopes <johnwcowan>and there is another extension to take the address of a label with the same constraint: the function you are jumping into must be on the stack <mwette>johnwcowan: thanks -- I'd didn't know it was that fancy. <johnwcowan>i think they implemented it so they could test code generation before writing a full front and/or transpiler