Re: Writing a C Compiler: lvalues

Marc van Lieshout <marc@lithia.nl> writes:
[...]
> An lvalue is an expression that evaluates to an address, so it *can* be
> used on the left hand side of an assignment.


Note that this is cross-posted to comp.lang.c and comp.compilers.
I'm posting this from comp.lang.c, and I'm using the C standard's
definitions of terms. C's definition of "lvalue" isn't necessarily
consistent with wider usage. For details, see
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>,
section 6.3.2.1.


No an lvalue is (roughly) an expression that *designates an object*.
(I say "roughly" because ``*ptr'' is an lvalue even if ptr==NULL.)


An lvalue can designate an object that has no address, such as
a bit field or a register variable. Conversely, an expression
that evaluates to an address, such as ``&obj'' is not necessarily
an lvalue.


The distinction, in C, between computing the address of an object
and "designating" an object is subtle but important.


It's very likely that the code generated for evaluating an lvalue will
compute the address of the designated object, which is relevant if
you're writing a compiler, but as far as C is concerned that's an
implementation detail that's not covered by the standard.


> But this is not necessarily
> the case. In an expression like (x + 5) x *is* an lvalue, but it isn't
> used as such, so it should be compiled as an ordinary rvalue.


C99 6.3.2.1p2:


        Except when it is the operand of [list of operators deleted],
        an lvalue that does not have array type is converted to the value
        stored in the designated object (and is no longer an lvalue).


So in (x + 5), x *isn't* an lvalue, even though it started out as one.


[...]


--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>

Return to the comp.compilers page.
Search the comp.compilers archives again.