Re: problems with forward invocation (gcc bug?)

[Richard Frith-Macdonald]

On Tuesday, July 31, 2001, at 11:58 AM, Wim Oudshoorn wrote:

> > If ffcall is not in use, the runtime still calls forward::
> > so the code in NSObject is there to handle that.
>
> However, this means that if user code implements
> - forward::
> it will behave differently if GNUstep is compiled
> with or without ffcall.
> I think that the OpenStep API does not specify
> if -forward:: is called or not, but I am not sure.

Correct ... forward:: is not in OpenStep ... the forwardInvocation: mehod
should be used by user apps.

> > I think this is really a compiler bug ... the compiler should know
> > how the method is being called, so it should generate the correct
> > type information.
> > IMO the types supplied by the compiler should
> > always reflect the actual arguments passed and return type expected
> > by the compiled code.
>
> This might not possible.  We know that -cString returns a (char *)
> but the offending line said:
>
> [x cString];
>
> And if the compiler only knows that x is of generic (id) type.
> How can it know what the return type of cString is supposed to be?

Good point ... I guess we can't call it a compiler bug then ... more
of a language bug.  Now if we had a type encoding for a return type
of 'dont care' the compiler could generate some info.
I think that, if the compiler doesn't know that a method is supposed to
return a struct, it's going to be unreliable anyway.

In truth, the forwarding mechanism in ObjC is fundamentally slightly
broken ... but it does well in all normal use.

> So the only solution I see is to assume that the
> return type for all selectors with the same name
> is identical (at least from the ffcall point of view).
> And if not, well issue a warning and good luck to you.

Unfortunately, it's definately the case that methods with the same
name can have different return types. Best we can do is ask the
receiver its type signature, and assume that the calling code
used something matching it.
Looking up a typed selector in the runtime is probably good enough for
almost ll cases.

> > An additional problem arises with Distributed Objects, the class to 
> > which
> > the message is being sent may not exist in the process, so the runtime
> > may not have any typed version of the selector at all!  In this 
> > situation
> > a methodSignatureForSelector: message should be sent to the object in 
> > the
> > remote process in order to find out what signature it expects - but the
> > existing code can't do that because it needs to send the message to the
> > receiver, but it can't unpack the receiver from the stackframe without
> > knowing what the return type is.
>
> But this would work (I think) because both sides NOW the method
>   methodSignatureForSelector:
> So this call would work.  The problem only arises when
> one process does not have the selector at all.

My point was that we can't send methodSignatureForSelector: to the 
receiver
reliably, because we can't pop the receiver off the stack reliably, 
because
we don't know whether the return type is a struct, because we don't have 
the
method signature, because ...

thus the need for the gs_objc_msg_forward() function to have two args.