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

[Ziemowit Laski <zlaski at apple dot com>]

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