In article <[email protected]>, David Holland <[email protected]> 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
