Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!ames!haven!mimsy!rlgvax!scc
From: scc@rlgvax.Reston.ICL.COM (Stephen Carlson)
Newsgroups: comp.lang.c
Subject: Re: What's an LValue [was A quick question]
Message-ID: <1991Mar14.190925.29741@rlgvax.Reston.ICL.COM>
Date: 14 Mar 91 19:09:25 GMT
References: <1991Mar12.030759.26698@nntp-server.caltech.edu> <31306@shamash.cdc.com> <1991Mar13.050555.26149@tandem.com>
Reply-To: scc@rlgvax.OPCR.ICL.COM (Stephen Carlson)
Organization: International Computers Limited
Lines: 35

In article <1991Mar13.050555.26149@tandem.com> jimbo@tandem.com (Jim Lyon) writes:
>In article <31306@shamash.cdc.com> bls@u02.svl.cdc.com (Brian Scearce) writes:
>>The rules are pretty easy (especially if you have your copy of
>>Harbison and Steele on your desk :-)
>>
>>0. variable names (excepting function, array and enum constant
>>   names) are lvalues.
>>1. e[k] is an lvalue, regardless of whether e and k are lvalues.
>>2. (e) is an lvalue iff e is.
>>3. e.name is an lvalue iff e is.
>>4. e->name is an lvalue regardless of whether e is an lvalue.
>>5. *e is an lvalue regardless of whether e is an lvalue.
>
>Rules (1) and (5) need to be further qualified.
[ Points well taken deleted, please refer to original article. ]

Rules (1) and (4) are technically redundant.

Since e[k] <=> *((e)+(k)), rule (1) is a special case of Rule (5).

Since e->name <=> (*e).name, rule (4) is a special case of Rules (3), (2),
and (5):
	*e			must be an lvalue	By rule 5
=>	(*e)		must be an lvalue	By rule 2
=>	(*e).name	must be an lvalue	By rule 3
=>  e->name		must be an lvalue	By definition of ->
Hence, rule (4).

However, it is better to present a practical set of rules than a logically
minimal set of rules.

-- 
Stephen Carlson           | ICL OFFICEPOWER Center    | In theory, theory and
scc@rlgvax.reston.icl.com | 11490 Commerce Park Drive | practice are the same.
..!uunet!rlgvax!scc       | Reston, VA  22091         |