On Thu, Dec 01, 2016 at 12:14:42PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > To make matters more fun, apparently[1] there are multiple variants of > > qsort_r with different argument orders. _And_ apparently Microsoft > > defines qsort_s, but it's not quite the same thing. But all of that can > > be dealt with by having more specific flags (HAVE_GNU_QSORT_R, etc). > > > > It just seems like we should be able to do a better job of using the > > system qsort in many cases. > > If we were to go that route, perhaps we shouldn't have HAVE_QSORT_S > so that Microsoft folks won't define it by mistake (instead perhaps > call it HAVE_ISO_QSORT_S or something). > > I like your suggestion in general. The body of git_qsort_s() on > systems without ISO_QSORT_S can do > > - GNU qsort_r() without any change in the parameters, > > - Microsoft qsort_s() with parameter reordered, or > > - Apple/BSD qsort_r() with parameter reordered. > > and that would cover the major platforms. > > Eh, wait. BSD and Microsoft have paramters reordered in the > callback comparison function. I suspect that would not fly very > well. You can hack around it by passing a wrapper callback that flips the arguments. Since we have a "void *" data pointer, that would point to a struct holding the "real" callback and chaining to the original data pointer. It does incur the cost of an extra level of indirection for each comparison, though (not just for each qsort call). You could do it as zero-cost if you were willing to turn the comparison function definition into a macro. -Peff