Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: What's an LValue [was A quick question]
Message-ID: <10898@dog.ee.lbl.gov>
Date: 13 Mar 91 17:44:30 GMT
References: <1991Mar12.030759.26698@nntp-server.caltech.edu> <31306@shamash.cdc.com> <1991Mar13.050555.26149@tandem.com>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 59
X-Local-Date: Wed, 13 Mar 91 09:44:30 PST

>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 :-)

[and then notes that this needs changes for ANSI C]

>>0. variable names (excepting function, array and enum constant
>>   names) are lvalues.

In ANSI C, arrays are also lvalues (but not modifiable lvalues).  This
is conceptually required to make sizeof() work without throwing in weird
rules.  (One can always argue that `non-modifiable lvalues' is a weird
rule :-) )

>>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.

In article <1991Mar13.050555.26149@tandem.com> jimbo@tandem.com
(Jim Lyon) writes:
>Rules (1) and (5) need to be further qualified.  e[k] and *e are
>lvalues regardless of whether e and k are lvalues, UNLESS the type
>of e[k] or *e is either Array... or Function...

Half of the qualifier is correct for ANSI C (*e is not an lvalue if e
has type `pointer to function (args) returning T').  In addition, the
type of e[k] may never% be `function ...' because for this to be true,
either:

	e has type `pointer to function ...'  and k has an integral type

or:

	e has an integral type and k has type `pointer to function ...'

and you cannot add an integer value to a pointer-to-function-... since
the size of a `function-...' is unknown.&

-----
% Well, maybe never.  Since *p \equiv *(p + 0) \equiv p[0], one could
  claim that

	int (*fp)(void);
	...
	(fp[0])();

  should have the same effect as `(*fp)();'.  I do not know what rules
  X3.159-1989 gives here (my copy is in my office; I am not).  Thus, if
  either e or k is the integral constant 0, perhaps e[k] may have type
  `function (args) returning T'.

& GCC permits adding integers to function-pointer values, by pretending
  the pointers are byte pointers.  This feature is of dubious utility
  (if you wanted to do that you could just cast to `char *' and back).
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov