cond. op. on ='s LHS

[Chris Torek]

>>In article <335 at ptcburp.ptcbu.oz.au> michi at ptcburp.ptcbu.oz.au
>>(Michael Henning) writes [abbreviated]:
>>>	int	array[10][10];
>>>	*array
>>>The type of the expression after dereferencing is "array of 10 ints", which
>>>is *not* an lvalue.

>In article <10069 at dog.ee.lbl.gov> I wrote:
>>Technically, the result *is* an lvalue (according to ANSI terminology,
>>at least)---but it is not a `modifiable' lvalue.

In article <337 at ptcburp.ptcbu.oz.au> michi at ptcburp.ptcbu.oz.au
(Michael Henning) writes:
>Hmmm..., I'm confused now. [quotes K&R and H&S]
>Neither K & R nor Harbison & Steele make any distinction between modifiable
>and non-modifiable lvalues.

Two points:

	a) both K&R and H&S exist in multiple editions (and K&R 2, at
	   least, exists in several versions; later printings have some
	   minor fixes).
	b) Neither K&R nor H&S claim to be the ANSI C standard.  For
	   that you must obtain X3.159-1989 from your local ANSI distributor.

The introduction of `modifiable' and `nonmodifiable' lvalues is new in
ANSI C; something like it is needed to make sense of `const int x = 3',
in which x is an lvalue but may not be assigned-to.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek at ee.lbl.gov