Re: What does "va_start and va_return type disagree" mean?

[Richard Frith-Macdonald]

On 6 Apr 2004, at 18:01, Philip Mötteli wrote:

> Hi
>
>
> I have a annoying Distributed Objects problem: I call a method
>
>         - (BOOL)saveFileToName:(bycopy NSString *)aName
>                 {
>                         return YES;
>                 }
>
> from a proxy. The method is called at the other end, but immediately 
> afterwards, the local end crashes, saying:
>
>         vacall: va_start type 14 and va_return type 3 disagree.
>         Program received signal SIGABRT, Aorted.
>
>
> The backtrace is:
>
>         #0 in kill () from /lib/i686/libc.so.6
>         #1 in pthread_kill () from /lib/i686/libpthread.so.0
>         #2 in raise () from /lib/i686/libpthread.so.0
>         #3 in raise () from /lib/i686/libc.so.6
>         #4 in abort () from /lib/i686/libc.so.6
>         #5 in __va_error1 () from /usr/lib/libcallback.so.0
>         #6 in GSInvocationCallback at GSFFCallInvocation.m:987
>         #7 in __vacall_r () from /usr/lib/libcallback.so.0
> 	#8 in returnTypeInfo () from 
> /usr/GNUstep/System/Library/Libraries/libgnustep-base_d.so.1
>         #9 in ?? ()
>         #10 in ?? ()
>         #11 in ?? ()
>
>
> Can anybody explain me, what DO wants to tell me?

I know it sounds unlikely, but I'd have though that this meant that the 
method in the remote process has a different return type to the method 
in the local process.

If the method is not declared in the local process, the compiler will 
have built the software to expect it to have a return type of 'id', so 
when it tires to return a 'BOOL' it can't.
The simple solution is to have a protocol declaring the method which is 
visible when the local process is compiled, so that the compiler knows 
to build the code to expect a BOOL return.