Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!caen!uflorida!travis!hcx2.ssd.csd.harris.com!sean
From: sean@hcx2.ssd.csd.harris.com (Sean Burke)
Newsgroups: comp.lang.c
Subject: Re: What's an LValue [was A quick question]
Message-ID: <2647@travis.csd.harris.com>
Date: 15 Mar 91 18:41:06 GMT
References: <1991Mar12.030759.26698@nntp-server.caltech.edu> <31306@shamash.cdc.com> <1991Mar13.050555.26149@tandem.com> <10898@dog.ee.lbl.gov>
Sender: news@travis.csd.harris.com
Reply-To: sean@hcx2.ssd.csd.harris.com (Sean Burke)
Organization: Harris Computer Systems Division, Fort Lauderdale, FL
Lines: 50

In article <10898@dog.ee.lbl.gov>, torek@elf.ee.lbl.gov (Chris Torek) 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 :-)
|> 
|> [and then notes that this needs changes for ANSI C]
|> 
|> >>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.
|> 
|> 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.&
|> 

So where would:

   struct { int array[10] ; } func() ;

   func().array[k]

fit into these rules?

I guess you could argue that its covered becuase

  func().array

is implicitly taking the address of something that is not an lvalue,
and thats an error in itself.