|Writing a C Compiler: lvalues firstname.lastname@example.org (=?ISO-8859-1?Q?Andr=E9_Wagner?=) (2010-05-08)|
|Re: Writing a C Compiler: lvalues email@example.com (Ben Bacarisse) (2010-05-09)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (bart.c) (2010-05-09)|
|Re: Writing a C Compiler: lvalues email@example.com (Tom St Denis) (2010-05-09)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Keith Thompson) (2010-05-09)|
|Re: Writing a C Compiler: lvalues email@example.com (Eric Sosman) (2010-05-09)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Stargazer) (2010-05-10)|
|Re: Writing a C Compiler: lvalues email@example.com (Marc van Lieshout) (2010-05-16)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Eric Sosman) (2010-05-17)|
|Re: Writing a C Compiler: lvalues email@example.com (Keith Thompson) (2010-05-17)|
|Re: Writing a C Compiler: lvalues firstname.lastname@example.org (Keith Thompson) (2010-05-19)|
|[6 later articles]|
|From:||Keith Thompson <email@example.com>|
|Date:||Sun, 09 May 2010 13:01:11 -0700|
|Organization:||None to speak of|
|Posted-Date:||09 May 2010 16:09:52 EDT|
AndrC) Wagner <firstname.lastname@example.org> writes:
> What I'm trying to say is: the compiler yields different assembly code
> for when 'x' is a lvalue and when 'x' is not a lvalue.
> This gets more confusing when I have expressions such as 'x++'. This
> is simple, since 'x' is obviously a lvalue in this case. In the case
> of the compiler, I can parse 'x' and see that the lookahead points to
> '++', so it's a lvalue.
> But what about '(x)++'? In this case, the compiler evaluates the
> subexpression '(x)', and this expression results the value of 'x', not
> the address. Now I have a '++' ahead, so how can I know the address of
> 'x' since all that I have is a value?
In C, a parenthesized lvalue is an lvalue.
> All documentation that I found about lvalues were too vague, and
> directed to the programmer, and not to the compiler writer. Are there
> any specific rules for determining if the result of a expression is a
The definitive document is the C standard. You can get a copy of the
1999 ISO C standard by sending money to your national standard body;
see, for example, webstore.ansi.org. Or you can get a free copy of
the latest post-C99 draft, incorporating the C99 standard plus the
three Technical Corrigenda, at
Technical Corrigenda themselves are available at no charge.
I wouldn't even consider trying to implement a compiler without
having a copy of the standard for the language.
Some relevant passages:
Except when it is the operand of the sizeof operator, the unary &
operator, the ++ operator, the -- operator, or the left operand
of the . operator or an assignment operator, an lvalue that
does not have array type is converted to the value stored in
the designated object (and is no longer an lvalue).
A parenthesized expression is a primary expression. Its
type and value are identical to those of the unparenthesized
expression. It is an lvalue, a function designator, or a void
expression if the unparenthesized expression is, respectively,
an lvalue, a function designator, or a void expression.
Note that the definition of "lvalue" in C99 184.108.40.206p1 is flawed, or
at least incomplete. An lvalue is not merely "an expression with
an object type or an incomplete type other than void"; it's such
an expression that designates, or that could designate, an object.
For example, int is an object type, and 42 is an expression of
type int, but 42 is not an lvalue. On the other hand, if ptr is a
pointer-to-int, *ptr is an lvalue, even if ptr==NULL (but attempting
to use it invokes undefined behavior).
Keith Thompson (The_Other_Keith) email@example.com <http://www.ghoti.net/~kst>
Return to the
Search the comp.compilers archives again.