Re: [libobjc] fix to nil_method

[Stan Shebs <shebs at apple dot com>]

Nicola Pero wrote:

[...]

> Then, the normal method invocation flow goes on as normal - the nil_method
> () function will be casted to whatever function was supposed to be
> executed to execute that method (that function will take an id, followed
> by a SEL, followed by who knows what arguments, depends on the method),
> and executed.
>
> Apparently, the usual definition of nil_method () can support this
> behaviour on usual machines, and the problem you get is because the usual
> definition doesn't work on your machine. :-(
>
> So, it looks to me that the fix should consist in implementing the
> 'nil_method ()' function so that it can be called in place of any function
> taking an 'id' argument followed by a 'SEL' argument, followed by zero, or
> one, or any number of arguments (both a fixed number, or a variable number
> !).
>
> If declaring it to take just an 'id' then a 'SEL' argument is enough to
> get this result (I suppose it depends on how function calls are
> implemented/compiled, about which I don't know much at the moment) - as in
> Honza's patch, then it's fine for me and the patch looks good.  If not,
> then the patch is not good.
The patch basically makes nil_method look non-variadic to the runtime,
and seems adequate as a workaround, since it would be pretty hard to
rewrite the codegen/runtime machinery to not fake up function
signatures.  So let's go with the patch, adding an explanatory
comment so that some energetic person doesn't come along and add
the signature back later. :-)

> Anyway I hope I explained the ObjC machine enough to let the
> stack/function calls/etc hackers find a way to fix it ... :-)
rth has grumbled about the use of builtin_apply, and of course
there is the related perennial problem with method encoding,
both of which are connected with ObjC trying to imitate the
standard GCC calling machinery at runtime, which is really hard
for some architectures.

Stan