[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with forward invocation (gcc bug?)
From: |
Richard Frith-Macdonald |
Subject: |
Re: problems with forward invocation (gcc bug?) |
Date: |
Tue, 31 Jul 2001 13:15:45 +0100 |
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.