Re: Writing a C Compiler: lvalues

Keith Thompson schrieb:
> lawrence.jones@siemens.com writes:
>> Keith Thompson <kst-u@mib.org> wrote:
>>> So in (x + 5), x *isn't* an lvalue, even though it started out as one.
>> I disagree -- x *is* an lvalue, but it's converted to the value stored in
>> the object when the containing expression is evaluated.
>
> A subtle distinction at best. As I wrote upthread, the standard says:
>
> 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 the above context, ``x'' *was* an lvalue, but "is no longer"
> an lvalue.


IMO the question should be rephrased as:


      What can be *used* as an lvalue?


in order to find out what value items can be elevated to lvalue items,
when required by the grammar.


As the name says, only an lvalue can occur at the left hand side of an
assignment. This IMO doesn't imply that it has an address (e.g. register
variables) or is mutable (by ++), so that other names should be used for
items that have further attributes, like "is-mutable" or "has-address"
for items usable with the address-of or auto-increment operator.


While a register-based local variable can be used as an lvalue inside
the procedure, it cannot be passed to a subroutine as a pointer. A
compiler can flag such a usage as an error, or it can (silently) remove
the "register" attribute from the variable declaration, in order to make
it eligible as a general lvalue.


Thus a compiler can have multiple rules, for what is acceptable as an
lvalue in various use-cases. A single simple "requires an lvalue" error
message IMO is inappropriate.


DoDi

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