Re: qsort_r

[christos%astron.com@localhost (Christos Zoulas)]

In article <20131208222953.GB25943%netbsd.org@localhost>,
David Holland  <dholland-tech%netbsd.org@localhost> wrote:
>(Cc: tech-kern because of kheapsort())
>
>My irritation with not being able to pass a data pointer through
>qsort() boiled over just now. Apparently Linux and/or GNU has a
>qsort_r() that supports this; so, following is a patch that gives us
>a compatible qsort_r() plus mergesort_r(), and heapsort_r().
>
>I have done it by having the original, non-_r functions provide a
>thunk for the comparison function, as this is least invasive. If we
>think this is too expensive, an alternative is generating a union of
>function pointers and making tests at the call sites; another option
>is to duplicate the code (hopefully with cpp rather than C&P) but that
>seems like a bad plan. Note that the thunks use an extra struct to
>hold the function pointer; this is to satisfy C standards pedantry
>about void pointers vs. function pointers, and if we decide not to
>care it could be simplified.
>
>This patch was supposed to have all the necessary support widgetry,
>like namespace.h changes, but there's at least one more thing not in
>it: MLINKS for the new functions and corresponding setlist
>changes. If I've forgotten anything else, let me know.
>
>heapsort() is used in one place in the kernel as kheapsort(), which
>takes an extra argument so that the heapsort code itself doesn't have
>to know how to malloc in the kernel. I have done the following:
>   - add kheapsort_r()
>   - change the signature of plain kheapsort() to move the extra
>     argument to a place it is less likely to cause confusion with the
>     userdata argument;
>   - update the caller for the signature change;
>but I have not changed the caller to call kheapsort_r instead. Based
>on the code, this should probably be done later as like many sort
>calls it's using a global for context. At this point the plain
>kheapsort can be removed.


LGTM.

christos