> So, gcc writes code in the stack and executes it?
> Oh, my gosh... how nauseating...

But pretty much unavoidable, if you're going to do nested functions.
The only ways to do nested functions are (a) stack trampolines (b)
function pointers fat enough to carry some sort of context ID along
with the code address, or (c) keeping some sort of minimal call stack
other than in the stack segment and put trampolines there.  (b) is the
cleanest, but is not compatible with code compiled by other (typically
vendor) compilers that use pure text segment addresses for function
pointers and pure-stack call frames.  Hence, since gcc is designed to
be usable on systems with vendor libc and such, it can't fatten
function pointers (even if it were possible to keep track of which
pointers are fat and which aren't, it wouldn't work for downward
funargs like the comparison routine for vendor qsort), so it does stack
trampolines.

On NetBSD, we could presumably use fat function pointers, since
everything is built with the same compiler, except that gcc as
distributed by the FSF isn't capable of that and it would probably be a
major change.  (Personally, I'd like to use fat function pointers,
since it would seriously break the (incorrect but common) assumption
that function pointers are the same size as data pointers, the same
size as ints, or the same size as anything else for that matter.)

In some cases (c) might be possible, but keeping the resulting stack
garbage-collected would be hell, especially in the presence of things
like longjmp()...and it would run into exactly the same problem
executing out of the data segment that we are currently seeing
executing out of the stack.

Fortunately :-), gcc doesn't do code-on-the-stack unless you actually
_use_ nested functions.  Unfortunately :-(, last time I looked it
appears to do it for all nested functions regardless of whether it
actually needs to for that function or not.  (Yes, I've written
functions as nested when they don't depend on anything not already at
file scope; it can be a useful device for keeping conceptually related
code together.  When combined with block expressions, the result feels
very much like a lambda expression in Lisp.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B