Re: qsort_r

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Dec 09, 2013 at 03:55:30AM +0000, David Holland wrote:
> On Sun, Dec 08, 2013 at 11:26:47PM +0000, David Laight wrote:
>  > > > 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.
>  > > 
>  > > I'd prefer to not have another indirect call. The only difference
>  > > is the definition and expanding a CMP macro differently?
>  > 
>  > Is just casting the function pointers safe in C (well in NetBSD)?
>  > (with the calling conventions that Unix effectively requires)
> 
> No. Well, it is, but it's explicitly illegal C and I don't think we
> should do it.

Actually given that these functions are in libc, their interface
is defined by the architecture's function call ABI, not by the C language.

Consider what you would do if you wrote an asm wrapper for qsort(a,b)
in terms of an asm qsort_r(a,b,d)?

For ABI where the the first 3 arguments are passed in registers
(eg: amd64, sparc, sparc64) and for ABI where arguments are stacked
and cleared by the caller (eg i386) I don't you'd consider doing anything
other than putting an extra label on the same code.

There might be ABI where the this isn't true - in which case the
'thunk' is an option, but I don't think NetBSD has one.

FWIW I think Linux is moving to an alternate ppc64 ABI that doesn't
use 'fat pointers'.

        David

-- 
David Laight: david%l8s.co.uk@localhost