throopw@dg_rtp.UUCP (01/29/87)
>,>>> rms@prep.ai.mit.edu (RMS) >> Doug Gwyn >>> ITEM 22, 3.2.2.1. This says that arrays are coerced to pointers >>> "where an lvalue is not permitted". >> This is not only correct, it is absolutely essential. > It is not correct. For example, lvalues are permitted as operands of > the binary `+' operator. According to the standard, it would follow > that arrays are not coerced to pointers when used as operands of `+'. This is tricky, because the definition of where lvalues are "permitted" is different in the X3J11 draft than in tradition. That tricky difference means that Doug is right, and RMS is wrong. The standard says, in 3.3.0.1: If an lvalue appears in a context where such an operand is not permitted, if it has array type is is converted to a pointer as described in 3.2.2.1, otherwise it is replaced by the value of the designated object. [...] The discussion of each operator identifies those where an lvalue [...] is permitted [...]. Since the discussion of the + operator is silent about lvalues, in X3J11 lvalues are NOT permitted as operands of the + operator. When lvalues occur as operands of the + operator (and in other places where they are not permitted), they are coerced to values. I think that this usage of the term "permitted" is at best murky and counterintuitive. But I don't have a specific counterproposal that really improves things, so I have kept quiet about it. -- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. --- Alan J. Perlis -- Wayne Throop <the-known-world>!mcnc!rti-sel!dg_rtp!throopw