casts and puns (and digressions...)

[jim at ISM780B.UUCP]

>/* Written  5:39 am  Nov  7, 1984 by rcd at opus in ISM780B:net.lang.c */
>/* ---------- "casts and puns (and digressions...)" ---------- */
>> ...  Do not be misled by the fact that some casts on some machines
>> generate no code.  A cast is a *conversion*, not a type pun...
>
>Unfortunately, not entirely true.  What C calls "casts" covers both
>true casts (in, say, the ALGOL 68 sense) and puns, at least in practice.
>The operation is a cast when conversion "makes sense" (in semantic terms);
>otherwise it's a pun.  For example, if i is an integer, (float)i is clearly
>a cast; it generates instructions on most machines and produces a different
>internal datum which is the float corresponding most closely to the
>integral value of i.  However, (long*)i is a pun; you just have to stretch
>too far to make any sensible semantics which makes it a true cast.

I quite disagree; even a bit-for-bit identity can be considered a conversion.
And there is no cast that might not generate code on some machine,
even pointer to integer or integer to pointer, since it may require
widening or truncation.  And, you are not even guaranteed a bit-for-bit
equivalence by the language spec (K&R, 14.4), only an "unsurprising" and
reversible mapping if the integer is large enough to hold the pointer.
Any assumption based on the notion of puns is likely to lead you
down the road to non-portability.

>> >example 'struct foo {struct foo *ref;};'...
>> struct foo is not a recursive type.  At best you might call it an
>> iterative type.  What would you think of struct foo {struct foo bar;}; ?
>
>Please be careful when attacking other folks' terminology.  Structured
>types which contain references to themselves are quite commonly called
>"recursive".  (See, for example, Hoare's seminal paper "Notes on Data
>Structuring".)

Chastisement accepted.

-- Jim Balter, INTERACTIVE Systems (ima!jim)