Re: NSInvocation return value location

[David Chisnall]

On 1 Dec 2008, at 16:12, Richard Frith-Macdonald wrote:

> On 1 Dec 2008, at 15:54, David Chisnall wrote:
>
> > I've looked at GSFFCallInvocation and I can't work out why changing  
> > the value of _retval does not alter where it stores the return  
> > value.  av_start_ptr appears to be called with _retval as the  
> > argument, but the result is written both to the location specified  
> > there and on the original stack location.
> >
> > Any hints?
>
> A vague guess (I haven't looked at that code for a while, and didn't  
> write it) ...  perhaps our code is passing the stack address to the  
> called method, and then on return from that method is copying the  
> data from the stack to the NSInvocation.

I don't think this is the case, since GSFFIInvocation does not exhibit  
this behaviour, meaning it must be due to something in the invocation  
itself, rather than in the caller.

> If you could get it fixed, that would be good, though I'm wondering  
> if we shouldn't deprecate ffcall in favour of ffi anyway, as using  
> ffcall seems to mess up the stack unwinding done by native objc  
> exceptions (meaning that an exception raised in a method called via  
> an invocation will cause the program to crash) and the stack trace  
> reporting done by exceptions (whether native or the more normal  
> setjmp/longjmp based implementation).

Having only one implementation would be simpler, certainly.  Ffcall  
seems to be built by default (it's what I had without specifying which  
to use).  Are there some platforms where only ffcall works?  If not,  
I'd be in favour of deprecating it...

David