On Thu, Mar 24, 2022 at 11:16:58PM -0400, Mouse wrote: > > The conclusion over the past ~25 years has been that there isn't; > > qsort and things like it work "well enough" and real uses for > > closures that really motivate the feature come up rarely enough that > > it doesn't happen. > > Nested functions are not closures, or at least not what I know as > closures. A nested function pointer (conceptually) goes invalid as > soon as anything it refers to goes out of scope, or at the latest as > soon as its smallest enclosing block exits (or possibly when its > smallest enclosing function returns). The thing I know as a closure > would preserve the referred-to objects as long as the closure is > potentially callable. This requires more reference tracking than C > typically makes possible.
There's a term for scope-restricted closures (that become invalid this way) that I'm currently forgetting. They're still closures in most of the important ways, and it's a useful concept for a language where copying memory isn't free. > > There is no solution based on trampolines that'll pass security (or > > at least security-theatre) muster. Unless maybe by doing something > > that's horrifying in other ways. > > The safest alternative that comes to my mind is to have two stacks, one > for trampolines and one for everything else. But that requires > something much like two stack pointers, including assist from the > setjmp/longjmp implementation and, if applicable, threads. That's not s3kure! You can still get arbitrary code execution by scribbling in it. > > (For example: you could declare a static limit on how many instances > > of the closure you'll ever produce, make a global array to stuff the > > data pointer in, and statically generate N trampoline entry points > > that read from that array and call the primary function. But there > > are many other ways in which this is horrible.) > > But there are use cases for which it is not a stupid implementation; > [...] I think to keep it safe you need more code analysis than you're likely to get with C code. But IDK. -- David A. Holland dholl...@netbsd.org
