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