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
