tech-kern archive

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

Re: qsort_r



[Should this maybe be moved to tech-toolchain?]

>>> My irritation with not being able to pass a data pointer through
>>> qsort() boiled over just now.
>> This sort of thing is one reason I do not consider nested function
>> support optional in any compiler I consider using: [...]
> Nested functions the way GCC implements them are broken.

I didn't say "nested function support the way gcc implements them".
Also, I disagree that they are broken.  They work; I use them
routinely.  You may find them inappropriate for your tradeoffs, but
that does not make them broken; it just means they're not a right tool
for you.

> For once, they introduce security issues by requiring an executable
> stack.

I think that's overstating the case; they require an executable stack,
which in some cases (an important qualification) can introduce security
issues.

Yes.  I don't like stack trampolines.  I would much prefer fat function
pointers.  One of my blue-sky projects has long been to build a
compiler that uses fat function pointers to do nested functions.  (I
haven't looked much at teaching gcc to do fat function pointers; the
little I've seen from when I _have_ had my fingers in gcc's internals
makes me suspect doing it in gcc would involve major surgery.)

> Anonymous functions with lexical scope can be done properly,

gcc-style nested functions are not anonymous.  (Admittedly, this is a
quibble.)

Yes, they can.  For many purposes, gcc's implementation is an example,
the above quibble aside.  But nothing says it's the only way; even I,
as inexpert as I am at compilers, can think of another implementation
technique I'm certain could be made to work which avoids the execution
out of the stack that bothers you so, another technique which probably
could be made to work (though I'm less sure), and there probably are
plenty of others I haven't thought of.

> They shouldn't be shoe horned into C this way though.

What's wrong with gcc's method?  Aside from implementation issues, that
is; I'm trying to see what you think is wrong with the language, not
the implementation of it, since you seem to think there _is_ something
wrong, at the language level, with gcc's version.  Or did I misread?

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index