[Bug libc/173] please consider a qsort_r function, similar to BSD

["znort99 at yahoo dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From znort99 at yahoo dot com  2008-05-04 00:55 -------

I think this should be re-opened.

Contrary to the argument presented in this bug, it is
actually really hard to properly implement qsort_r on
top of qsort (short of using a trampoline or entirely
re-coding quicksort).

Rationale against the arguments presented:

>There are already now ways how to do that even without qsort_r:
>a) store the state to __thread variables

This may be thread safe, but it is not re-entrant,
which is what the original poster needed (and what
I find myself needing as well)

>b) use GCC nested functions

This obliges you to write GCC specific code.
As elegant as this solution may be, and as much as we all
like GCC, this is a non standard feature and makes your code
unportable to non-GCC environments.

>c) use pthread_getspecific

Again an ugly band-aid (in this case a global variable
hidden in a posix thread function). Depending on your OS
and implementation of posix threads, this might also very
well be dog slow.

Finally: this is again not reentrant.

d) use locking around the qsort invocation

Again: not re-entrant. If the compare function
finds itself in need of sorting against a second
key to get an answer, you're dead in the water.

Please, please, please re-consider making
qsort_r part of glibc.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=173

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.