Re: Nested functions [was Re: valgrind]

[David Holland <dholland-tech%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost