[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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 Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |