Re: problems with forward invocation (gcc bug?)

[Wim Oudshoorn]

You wrote:
> Wim Oudshoorn wrote:
> > > a) there is only a single definition of cString - in this case the
> > > return type is obvious and taken by the compiler
> > But still, with x being `id', the selector is untyped, regardless
> > if the compiler generates the correct calling sequence.
>
> Ok. This is some kind of compiler 'bug' (the compiler isn't *required*
> to generate typed selectors by language definition).

Agreed.  And it is not always possible.

> It isn't really a bug, since if the selector is untyped, you can always
> retrieve the type using [x methodSignatureForSelector:...] in the
> NSInvocation code. Carrying the type with the selector is only a speed
> optimization.
> I didn't fully follow the discussion, but I can't see problems so far.
>

Well, I see a problem ;-) Ok, the problem is the following, as pointed
out by Richard Frith-Macdonald.

A.  In forwarding code you NEED the return type in order to
    retrieve the receiver from stack.
B.  You need the receiver to correctly determine the return
    type.

The problem in practice is not as bad as it appears.
Most of the time the stack frame is just as you would
expect and you do not really need the type of the return value.
However, if GCC thinks that the method call returns a large
struct, it will add an hidden parameter (the address of the
struct in which to put the data), and this paramter screws
up the stack frame layout.

So as you can see, what is needed is not actually the type
of the selector, BUT the return type that the compiler expects.

Best would be if the compiler generates a typed selector
for all method invocations, where the type describes
the stack layout used in the call.  But things work
pretty well without that :-)

> > I do not have gcc here, but I think that
> >
> > @selector (selectorThatIsNeverDefined);
> >
> > does not result in a warning by gcc.
>
> No, why should be that ? A selector is just a name in this case.

I agree.  I misunderstood your first post.