Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tdatirv!sarima
From: sarima@tdatirv.UUCP (Stanley Friesen)
Newsgroups: comp.lang.c
Subject: Re: cond. op. on ='s LHS
Message-ID: <149@tdatirv.UUCP>
Date: 21 Feb 91 16:21:08 GMT
References: <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: sarima@tdatirv.UUCP (Stanley Friesen)
Organization: Teradata Corp., Irvine
Lines: 53

In article <337@ptcburp.ptcbu.oz.au> michi@ptcburp.ptcbu.oz.au (Michael Henning) writes:
|Hmmm..., I'm confused now. From K & R:
|
|"An *object* is a manipulatable region of storage; an *lvalue* is an expression
|referring to an object.  [...] ...

|From Harbison & Steele:
|
|"An "lvalue" is an expression that refers to an object in such a way that the
|object may be altered as well as examined.  [...] ...

Note that these definitions are *different*.  The K&R definition does *not*
imply that an lvalue may be used on the left hand side of an assignment.

|Neither K & R nor Harbison & Steele make any distinction between modifiable
|and non-modifiable lvalues. Furthermore, both say that the result of
|applying a dereference operator to a pointer *always* yields an lvalue,
|and that the left operand of an assignment operator must be an lvalue.
|Yet, if "array" is a two dimensional array, then "*array", by definition, is
|an lvalue, but "*array" cannot appear on the left hand side of an assignment
|statement, since the usual unary conversions (conversion to a pointer in this
|case) do not take place for the left operand, and the type of the left
|operand is "array of 10 ints".
|I get the impression that there simply are some inconsistencies in the
|language definition.

Quite correct.  The definitions and constraints as presented in the non-ANSI
texts are *inconsistant*!   This is why the ANSI committee decided to clarify
the matter.  They chose to use the K&R definition of lvalue, and to revise the
constraint on assignment operators to require a *modifiable* lvalue as the
left operand.  They chose this approach largely because it simplified the
semantics of the 'const' qualifier - a 'const' expression can simply be
described as one that refers to an object that cannot be modified.  Now
both the restriction against assignment to arrays and the proper restrictions
on the use of 'const' entities are captured in a single constraint on
assignments and a single definition (of 'modifiable lvalue').  This also
allowed the C standard to retain the simple rule that a dereference *always*
yields an lvalue.

|Either an object is an lvalue, in which case it can
|be used as the left operand of an assignment, or it isn't, in which case
|it cannot be used that way. I believe that the issue could be cleaned up
|by changing the definition of "*" to say something like ...
 
|Something to that effect should clean things up. Any comments anyone ?

Except that the ANSI committee has already cleaned things up the other way,
and with less complexity - since non-modifiable lvalues are the best way
to handle 'const' anyway.  [Trying to say that a 'const' variable does
not yield an lvalue leads to a very complex definition for lvalue].
-- 
---------------
uunet!tdatirv!sarima				(Stanley Friesen)