[comp.lang.c] Casting to array type

throopw@xyzzy.UUCP (Wayne A. Throop) (01/18/88)

> boemker@hpfcdc.HP.COM (Tim Boemker)
>> [... (if it were legal) the expression cast to array type ...]
>> being subscripted would have to be a temporary
>> array (with, for this reason, no aliases), and the whole assignment
>> becomes a monumentally obfuscated no-op.
>    Using an expression of type array is defined, and the object referenced
>    is not the whole collection of elements but a pointer to the collection
>    (pp. 195 bottom and 210 top).

This assertion is somewhat misleading.  In particular, the passages
appealed to above do not say that an expression of type array *refers*
to a pointer, but that it is (usually) *converted* to a pointer.  The
exception to this rule, when target of sizeof, makes this distinction
clear.  A "conversion" is not a "reference".  And "conversion" is not
commutative, so the conversion from array to pointer in no way implies
that a conversion from pointer to array is legal.

>    Saying that the resulting expression would
>    have to be a temporary array does not make sense under K&R, and it shows
>    a misunderstanding of its concept of arrays: every array expression of
>    the form A[i] is equivalent to the pointer expression *(A+i).

It shows no such thing.  Remember the context here: I said that was what
would happen *IF* the cast made sense in K&R, which it does not.
Pointing out that a temporary array doesn't make sense in K&R is exactly
the illegality I was suspending for the purposes of discussing what that
expression might mean.

I said that the resulting expression would have to be a temporary array
because that is what casting is all about.  Or, more precisely, casts
always result in rvalues, and an rvalued array is an oxymoron under K&R.
Both the tutorial and reference sections on casts are very explicit
about this in K&R.  The tutorial says that casts work as if by
assignment to a temporary of the cast type.  This is clearly impossible
for arrays.  The syntax in the reference makes it clear that casts
result in rvalues.  Again, this is impossible for arrays.

However, I can see now (I think) what Tim is getting at.  Which is, why
isn't the cast ((type [N])E) equivalent to the cast ((type *)E)?  And
the answer is that this special case was not allowed for in K&R.  The
equivalent special case, making these two types equivalent when they
appear as formal arguments, *was* made, but it is, indeed, a special
case, and the analogous special case for casts was *not* made.  Whether
it should have been made or not is moot: the point is that it *was*
*not* made.  (And in my humble opinion, the special case for array
formal arguments should not have been made either.)

--
Giving up on assembly language was the apple in our Garden of Eden:
Languages whose use squanders machine cycles are sinful.  The LISP
machine now permits LISP programmers to abandon bra and fig-leaf.
                                                --- Alan J. Perlis
Moon calls them Fortran Machines and Lisp Machines,
but I would prefer to call them fuzzy mammals and
pterodactyls myself.
                                                --- Richard P. Gabriel
-- 
Wayne Throop      <the-known-world>!mcnc!rti!xyzzy!throopw