Why does casting a function generate a run-time abort?

[Ziemowit Laski]

On 18 Jun 2004, at 16.08, Richard Henderson wrote:

> On Fri, Jun 18, 2004 at 03:53:04PM -0700, Ziemowit Laski wrote:
>> Because at least you know what you're calling, instead of having to 
>> talk
>> back to the front-end du jour to find out.
>
> We know what we're calling -- a method.  It's the details of how
> to find out exactly that method's address that's private to the
> front end.

A front-end deciding on an address of a method?  Doesn't the linker 
usually
do this? :-)

>
>>> Because you're NOT WRITING C.  Because you're ALREADY outside the
>>> semantics of the C language, and so ...
>>>
>>>> for it guarantees
>>>> that ObjC is as portable as the C language underneath it.
>>>
>>> ... this says that you CAN NOT do what you're trying to do.
>>
>> Except that I _did_ do  it, using a code fragment you described as
>> "overly complicated". :-)
>
> No, you did NOT.  You wrote something that looked like C, but
> was not semantically valid C.  Thus you did not write in C.

It was not strict standard-conforming C, I'll give you that.  But it
definitely was GNU C (which, of course, the compiler we're both working
on supports).  Of course, the original cast _was_ standard-conforming...

> Do you really want to continue arguing about this?

No. :-)

>  You're not the
> one that has to work on the optimizers, after all.

No, not usually, but the reason I started this thread is to find a way 
to solve
the temp variable bloat that we're getting hit with in ObjC.  And I 
think I
found it. :-)  In the future, if/when you implement your METHOD_EXPR 
doomsday
machine, I'll happily take a look at it, but right now we really need
to reduce the ObjC code bloat we're seeing with gcc 3.5.

Thanks,

--Zem