Casting Question

[throopw at dg_rtp.UUCP]

> I am relatively new to the language (C) and so was puzzled by the
> following ....
>    typedef int (*Inst)();
>    Inst    *pc;
>    ifcode() {
>        Inst *savepc= pc;
>        pc = *((Inst **)(savepc+2));
>    }
> I understand that the cast makes it (savepc+2) a pointer to a pointer to
> an Inst (or a pointer to a pointer to a pointer to a function returning
> an integer).  But then the de-referencing star on the outside takes one
> level of indirection away, making savepc+2 what it was anyway ( a
> pointer to a pointer to a function returning an integer.)

Yes and no.  Mostly no.  It makes it the same *type* it was before, but
the *meaning* is completely different.  This is a trick that was worried
over in net.lang.c some time before.  Actually, Inst *wants* to be
declared to be

            typedef Inst (*Inst)();
and used as
            pc = *(savepc+2);

but C doesn't allow this type of recursive definition.  The alternative
is to use "int" as a primitive type to "bottom out" the recursion, and
then use the cast to keep lint happy about assigning a pointer to a
function returning int to what wants to be a pointer to a pointer to a
function returning int.  Clear?  If not (and there is demand by mail) I
can repost some of the explaination that went by here a while back.

> I compiled hoc and tested the if statement; it worked.  I edited code.c
> and removed the seemingly extraneous cast and de-ref: it still worked.

I am not surprised.  The statement

        pc = *((Inst **)(savepc+2));

implies the same bit-wise manipulation (on most machines) as

        pc = *(savepc+2);

But there is a crucial difference.  In the latter case, "pc" is being
assigned a pointer of the wrong type, and lint will complain.  In the
former case, the types match, and no complaint ensues (unless you have a
barbaric lint that complains about all pointer casts, as some seem to
do).

Now, why is the difference crucial?  Because on some machines, it may
conceiveably be important to have these types match correctly.
-- 
Wayne Throop at Data General, RTP, NC
<the-known-world>!mcnc!rti-sel!dg_rtp!throopw