tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Nested functions [was Re: valgrind]



On Tue, Mar 22, 2022 at 09:16:36PM -0400, Mouse wrote:
 > Indeed, you can have different sizes for pointers to different object
 > types, too.  I _think_ pointers to different function types can have
 > different sizes, but I'm less certain of that.  (There would be little
 > point, since all function pointer types have to have the same
 > information content; see below.)

I don't think they can, but I wouldn't swear to it and, as you note,
it's a moot point.

 > > However there are, I fear, too many programs that somewhere convert a
 > > function pointer to (void *) and at that point things break.
 > 
 > That is a bug.  It always has been.  Such code is broken and it
 > deserves to be rednered _obviously_ broken so it can get fixed.

...and it already doesn't work on some platforms. I don't think
there's actually that much of this and finding it is a fairly
straightforward static analysis problem.

That said, moving to fat function pointers on machines that don't
already use them is a real ABI change and therefore a big deal; but it
could be done if there were a compelling argument to justify going
through all the associated dark rituals.

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. And that's why we are where we are.

(More than ~25 years ago people probably cared, or purported to care,
about an extra 4 bytes per function pointer enough to consider it not
worthwhile on those grounds.)

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.

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

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index