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

[Ziemowit Laski]

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

> On Fri, Jun 18, 2004 at 03:03:24PM -0700, Ziemowit Laski wrote:
>> Why not?
>
> Because it's overly complicated in ways that don't help at all.

No, but seriously.

>> Of course, you do realize that objc_msgSend is not the only entry 
>> point
>> we'd need to handle in this fashion?
>
> Ok, so?
>
>> Do you want to have a different METHOD_EXPR for each of them (and for
>> new entry points that the GNU and/or NexT runtimes may throw your way
>> in the future)?
>
> Aside from the exact set of places that METHOD_EXPR can be found
> in gimple, the meaning of METHOD_EXPR is entirely private to the
> front end.  Thus you can have it expand to anything that the
> front end cares to do.

But I thought that METHOD_EXPR was intended to be a front-end-agnostic
GIMPLE construct.  If METHOD_EXPRs are supposed to be private to the 
front-end,
then why can't I enjoy the asm(...) renaming trick in the privacy of
the ObjC front-end as well?
>
> This argument, imo, misses the point.
>
>> Perhaps a more generic solution would involve a CAST_CALL_EXPR, where
>> one of the arguments is the function to be called (objc_msgSend in our
>> example), and another the signature to use for this particular call.
>> Still redundant (at least of ObjC), but at least more sane. :-)
>
> In what way is this sane?

Because at least you know what you're calling, instead of having to talk
back to the front-end du jour to find out.  Unless I'm misunderstanding 
your
METHOD_EXPR proposal...
>
>>> I think you definitely want to NOT think about things you could 
>>> sort-of
>>> represent with C.
>>
>> Why not?  I think you absolutely _do_ want to 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". :-)

> Would you make the same argument that C++ or Java or Ada must be
> completely implementable in C?

Yes, of course I would; I am sure you have come across 'cfront' in the 
past? :-)
C is a Turing-complete language, is it not?

--Zem