Re: problems with forward invocation (gcc bug?)

[Wim Oudshoorn]

> 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.

This reminds me,
last weekend while I looked through the ffcall library
and the GCC info file documentation I wondered how in
the C language GCC handles the following:

FILE1 defines and implements

struct aStructure getAStructure (int anArgument) { ... }

FILE2 contains a call
...
    getAStructure (42);
....

ignoring the return type and without including the
prototype for `getAStructure'.
If GCC does generate an hidden first argument
(a pointer to the return struct) how does it know
if it has to generate one in FILE2?
Of course you get a warning, so in practice it would
not be that big of a problem.   But in Objective-C
it IS a problem.


> 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

Ok, I probably miss something.  (I haven't looked at DO and
how it actually works!) But, I still think it should work:

Let's assume that the calling process and the called process
use GNUstep. Than BOTH processes do have an implementation for
`methodSignatureForSelector:' (probably for NSObject
but I do not have the sources at hand)
So BOTH processes now the precise signature for this
particular selector!

But how do you manage this across different platforms?
You can not assume that the stackframe is layed out in
the same way on both machines.

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

Well, this might not solve all of the problems:
Assume that we have two methods with the same name:

class A: - (int)             getAValue: (int) anArgument
class B: - (struct aStruct)  getAValue: (int) anArgument

And suppose we call on a untyped object `x'

[x getAValue: 42];
returnStruct = [x getAValue: 42];

Ok, now my guess is that in the first case the stackframe will look something
like:

First case:     object x, selector `getAValue', 42
Second case:    adress of returnStruct, object x, selector `getAValue', 42

And gs_objc_msg_forward() can not distinguish between the two because:
IT DOES NOT KNOW HOW IT IS CALLED!

So it probably will only work when:
A. the compiler generates the exact calling type info.
B. the forwarding uses this for the popping of the arguemnts
   AND checks if the expected return type and the actual return
   type match.
But I have to think about this.  There are probably problems with
this approach also.

This also begs the question, do we aim for a robust solution, one that
never crashes but forbids some perfectly legal code.
Or do we aim for an approach that will work in most cases but crashes
in some obscure circumstances.

Wim Oudshoorn.