Bug 173

The FreeBSD manual page for qsort_r() is available from
<URL: http://www.freebsd.org/cgi/man.cgi?query=qsort >.  It specifies

  #include <stdlib.h>
  [...]
  void
  qsort_r(void *base, size_t nmemb, size_t size, void *thunk,
          int (*compar)(void *, const void *, const void *));
  [...]
  The qsort_r() function behaves identically to qsort(), except that
  it takes an additional argument, thunk, which is passed unchanged
  as the first argument to function pointed to compar.  This allows
  the comparison function to access additional data without using
  global variables, and thus qsort_r() is suitable for use in
  functions which must be reentrant.

There are already now ways how to do that even without qsort_r:
a) store the state to __thread variables
b) use GCC nested functions
c) use pthread_getspecific
d) use locking around the qsort invocation

I'll suspend this bug.  I haven't seen any interest in this code ever and as
Jakub pointed out, there are plenty of methods to make things work with qsort. 
Especially on reasonable systems which have __thread support.

If there should be more interest (which can be demonstrated!) the bug can be
activated again.

Alternatively, you can try to get the function standardized by POSIX.

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.

Also, re-reading the comment Ulrich made about
why there should be interest in this function,
you may want to take a look at how glib had to
solve the problem. They basically had no choice
but to re-implement quicksort:

http://www.google.com/codesearch?hl=en&q=+g_qsort_with_data+show:KCTGLOhTfYQ:Un7Mc9xTPvU:xo7tCazfQxw&sa=N&cd=1&ct=rc&cs_p=ftp://ftp.gtk.org/pub/gtk/v2.4/glib-2.4.1.tar.bz2&cs_f=glib-2.4.1/glib/gqsort.c#first

Such a function has been added some time ago.