Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!ucsd!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: cond. op. on ='s LHS
Message-ID: <10107@dog.ee.lbl.gov>
Date: 21 Feb 91 11:43:59 GMT
References: <11073@pasteur.Berkeley.EDU> <15184@smoke.brl.mil> <326@smds.UUCP> <1196@sheol.UUCP> <331@smds.UUCP> <1210@sheol.UUCP> <335@ptcburp.ptcbu.oz.au> <10069@dog.ee.lbl.gov> <337@ptcburp.ptcbu.oz.au>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 31
X-Local-Date: Thu, 21 Feb 91 03:43:59 PST

>>In article <335@ptcburp.ptcbu.oz.au> michi@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@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@ptcburp.ptcbu.oz.au> michi@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@ee.lbl.gov