Whats an lvalue?

[nobrow]

Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...

a
*a
a[1]
*(a + 1)
....
What else?

What grammar/regexp describes all valid lvalues?

 

[Eric Sosman]

Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...

a
*a
a[1]
*(a + 1)
...
What else?

All of these might or might not be lvalues, depending
on what `a' is.

What grammar/regexp describes all valid lvalues?

It would be straightforward, although tedious, to write
a grammar that generates all lvalue expressions, but it would
also accept some expressions that are not lvalues. The
property of being an lvalue is semantic, not grammatical.

 

[Rg]

[...]

a
*a
a[1]
*(a + 1)
...
What else?

All of these might or might not be lvalues, depending
on what `a' is.

[...]

Why do you say *a, a[1] and *(a + 1) may not be lvalues? For as much
as know, the unary * operator and the [] operator always require an
expression that represents a valid object's address, and they always
return lvalues.

rg

 

[Eric Sosman]

Rg wrote On 03/06/07 13:11,:

[...]

a
*a
a[1]
*(a + 1)
...
What else?

All of these might or might not be lvalues, depending
on what `a' is.

[...]

Why do you say *a, a[1] and *(a + 1) may not be lvalues? For as much
as know, the unary * operator and the [] operator always require an
expression that represents a valid object's address, and they always
return lvalues.

int a[5][10];
a[1] = ...?

 

[Eric Sosman]

Eric Sosman wrote On 03/06/07 13:41,:

Rg wrote On 03/06/07 13:11,:

[...]



a
*a
a[1]
*(a + 1)
...
What else?

All of these might or might not be lvalues, depending
on what `a' is.

[...]

Why do you say *a, a[1] and *(a + 1) may not be lvalues? For as much
as know, the unary * operator and the [] operator always require an
expression that represents a valid object's address, and they always
return lvalues.

int a[5][10];
a[1] = ...?

On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:

int a(void);
*a = ...?

 

[Old Wolf]

Eric Sosman wrote On 03/06/07 13:41,:

int a[5][10];
a[1] = ...?

On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:

int a(void);
*a = ...?

In C99, a[1] is not an lvalue if it does not designate valid storage,
eg.
char *a = NULL;
a[1];

 

[nobrow]

Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...

a
*a
a[1]
*(a + 1)
...
What else?

What grammar/regexp describes all valid lvalues?

Purely syntactically though, can you write a grammar that recognizes
valid lvalues.

 

[Eric Sosman]

Old Wolf wrote On 03/06/07 16:46,:

Eric Sosman wrote On 03/06/07 13:41,:

int a[5][10];
a[1] = ...?

On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:

int a(void);
*a = ...?

In C99, a[1] is not an lvalue if it does not designate valid storage,
eg.
char *a = NULL;
a[1];

Perhaps the verbiage changed; my C99 is not close at
hand for checking. In TC2 (May 2005), a[1] is an lvalue

"An /lvalue/ is an expression with an object type
or an incomplete type other than void;"

The fact that `a' is NULL doesn't destroy the lvalue-ness,
but causes other problems instead:

"if an lvalue does not designate an object when it
is evaluated, the behavior is undefined."

(Both quotes from 9899:TC2, section 6.3.2.1 paragraph 1.)

To get back to the O.P.'s question, though: I don't
believe it's possible to distinguish lvalues from non-
lvalues on purely syntactic grounds (the grammar in the
Standard does not do so), and it's certainly beyond the
reach of a regular expression.

 

[Keith Thompson]

Eric Sosman wrote On 03/06/07 13:41,:

int a[5][10];
a[1] = ...?

On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:

int a(void);
*a = ...?

In C99, a[1] is not an lvalue if it does not designate valid storage,
eg.
char *a = NULL;
a[1];

The C90 definition of "lvalue" was badly messed up. The C99
definition is arguably worse. Neither one completely captures the
intended meaning.

C90 6.2.2.1 says:

An _lvalue_ is an expression (with an object type or an incomplete
type other than void) that designates an object.

That's close to the actual intent, but there's a problem: taken
literally, it implies that certain expressions may or may not be
lvalues depending on their current value. For example:

int x;
int *ptr = &x;
/* *ptr is an lvalue, since it designates the object x. */
ptr = NULL;
/* *ptr no longer designates an object. */

But where the standard requires an expression to be an lvalue, it's a
constraint that must be satisified at compilation time.

C99 tried and failed to fix the definition. C99 6.3.2.1p1:

An _lvalue_ is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an object
when it is evaluated, the behavior is undefined.

That avoids the problem with the C90 definition, but it fails to
express the idea that designating an object is what lvalue-ness is all
about. A literal reading of the C99 definition says that 42 is an
lvalue (it's an expression of type int, and int is an object type),
and that any attempt to evaluate the expression 42 invokes undefined
behavior.

The *intent* is that an lvalue is an expression that *potentially*
designates an object, i.e., that can do so for certain values of the
expression and its subexpressions. *ptr is an lvalue whether
*currently* designates an object or not; if it doesn't currently
designate an object, attempting to use it *as an lvalue* invokes
undefined behavior.

(The older, pre-ANSI meaning of the term "lvalue" is not the
expression itself, but the result of evaluating an expression to
determine what object it designates, as oppposed to an "rvalue" which
is what ISO C simply calls the value of the expression.)

 

[Eric Sosman]

Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...

a
*a
a[1]
*(a + 1)
...
What else?

What grammar/regexp describes all valid lvalues?

Purely syntactically though, can you write a grammar that recognizes
valid lvalues.

(It seems you haven't been paying attention ... Ah, well.)
Here is a regular expression that matches all lvalues:

.*

Have fun!

 

[nobrow]

Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...
a
*a
a[1]
*(a + 1)
...
What else?
What grammar/regexp describes all valid lvalues?

Purely syntactically though, can you write a grammar that recognizes
valid lvalues.

(It seems you haven't been paying attention ... Ah, well.)
Here is a regular expression that matches all lvalues:

.*

Have fun!

Cute ... Ill see how far I get with .*

All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.

The original motivation is now gone, and this is now purely an
academic question.

 

[Eric Sosman]

[...]
All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.

The original motivation is now gone, and this is now purely an
academic question.

nobrow, it's been explained -- several times -- that
"lvalue-ness" is not a syntactic property. The definition
of lvalue has been quoted, from multiple versions of the
C Standard (the text has changed over time). The only
"syntactical" piece is that an lvalue must be an expression,
so we can conclude (for instance) that ;-) cannot be part
of an lvalue because it cannot be part of an expression.
We can also conclude (see Keith Thompson's post) that 42
is not an lvalue even though it is a syntactically valid
expression. But there remains a large class of expressions
that might or might not be lvalues, depending on the context.
It's not a syntactic question, certainly not for a context-
free grammar.

Very few languages are fully described by their syntax.

 

[Keith Thompson]

[...]
All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.

The original motivation is now gone, and this is now purely an
academic question.

nobrow, it's been explained -- several times -- that
"lvalue-ness" is not a syntactic property. The definition
of lvalue has been quoted, from multiple versions of the
C Standard (the text has changed over time). The only
"syntactical" piece is that an lvalue must be an expression,
so we can conclude (for instance) that ;-) cannot be part
of an lvalue because it cannot be part of an expression.
We can also conclude (see Keith Thompson's post) that 42
is not an lvalue even though it is a syntactically valid
expression. But there remains a large class of expressions
that might or might not be lvalues, depending on the context.
It's not a syntactic question, certainly not for a context-
free grammar.

Very few languages are fully described by their syntax.

True, but there's a reasonable question buried in there. Is there a
subset of exressions, defined syntactically, such that any member of
that subset *might* be an lvalue, and any expression not in that
subset *cannot* be an lvalue? Obviously the set of all expressions
meets that requirement, but what is the *minimal* subset, defined
syntactically, that includes all possible lvalues?

You could probably do it by considering the top-level operator of the
expression. For example, if the top-level operator is unary "sizeof",
unary "+", unary "-", multiplication, division, a bitwise or shift
operator, etc., then the expression cannot be an lvalue; if the
top-level operator is "[]", "->", etc., then it may be an lvalue. You
also have to allow for parentheses, and remember than x+y or x-y can
be an lvalue if x or y is a pointer.

 

[Joe Wright]

[...]
All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.

The original motivation is now gone, and this is now purely an
academic question.

nobrow, it's been explained -- several times -- that
"lvalue-ness" is not a syntactic property. The definition
of lvalue has been quoted, from multiple versions of the
C Standard (the text has changed over time). The only
"syntactical" piece is that an lvalue must be an expression,
so we can conclude (for instance) that ;-) cannot be part
of an lvalue because it cannot be part of an expression.
We can also conclude (see Keith Thompson's post) that 42
is not an lvalue even though it is a syntactically valid
expression. But there remains a large class of expressions
that might or might not be lvalues, depending on the context.
It's not a syntactic question, certainly not for a context-
free grammar.

Very few languages are fully described by their syntax.

True, but there's a reasonable question buried in there. Is there a
subset of exressions, defined syntactically, such that any member of
that subset *might* be an lvalue, and any expression not in that
subset *cannot* be an lvalue? Obviously the set of all expressions
meets that requirement, but what is the *minimal* subset, defined
syntactically, that includes all possible lvalues?

You could probably do it by considering the top-level operator of the
expression. For example, if the top-level operator is unary "sizeof",
unary "+", unary "-", multiplication, division, a bitwise or shift
operator, etc., then the expression cannot be an lvalue; if the
top-level operator is "[]", "->", etc., then it may be an lvalue. You
also have to allow for parentheses, and remember than x+y or x-y can
be an lvalue if x or y is a pointer.

Well no. x+y is always an rvalue. *(x+y) has a chance of being an lvalue.

With all respect to you and Eric and all the rest, I contend we make too
much of the 'complexity' of what an lvalue might be. I first encountered
the term in K&R1 circa 1978. That definition was clear to me 20 years
ago when I read it and satisfies me today. To wit: p183 A.5 "Objects and
lvalues"

"An object is a manipulatable region of storage; an lvalue is an
expression referring to an object."

It worked for me then and it does now. KISS.

Also an rvalue is any expression not an lvalue.

In my own view, even though an expression might refer to an object, it
becomes an lvalue only on the left of an assignment operator.

Consider:

int a, b, c; /* a, b and c are (refer to) objects */

a = 5; /* a is an lvalue */
b = a + 4; /* b is an lvalue, a is an rvalue and a + 4 is 9 */

 

[Keith Thompson]

Keith Thompson wrote: [snip]

You could probably do it by considering the top-level operator of the
expression. For example, if the top-level operator is unary "sizeof",
unary "+", unary "-", multiplication, division, a bitwise or shift
operator, etc., then the expression cannot be an lvalue; if the
top-level operator is "[]", "->", etc., then it may be an lvalue. You
also have to allow for parentheses, and remember than x+y or x-y can
be an lvalue if x or y is a pointer.

Well no. x+y is always an rvalue. *(x+y) has a chance of being an lvalue.

D'oh, you're right.

In fact, *(x+y) is definitely an lvalue (if neither x nor y is a
pointer, then it's illegal).

With all respect to you and Eric and all the rest, I contend we make
too much of the 'complexity' of what an lvalue might be. I first
encountered the term in K&R1 circa 1978. That definition was clear to
me 20 years ago when I read it and satisfies me today. To wit: p183
A.5 "Objects and lvalues"

"An object is a manipulatable region of storage; an lvalue is an
expression referring to an object."

It worked for me then and it does now. KISS.

Agreed -- with the small proviso that an expression may be an lvalue
even if it doesn't *currently* refer to an object (but if it doesn't,
and it's used in a context requiring an lvalue, then the behavior is
undefined). For example, *ptr is an lvalue even if ptr == NULL.

Also an rvalue is any expression not an lvalue.

Um, not really. The standard doesn't use the term "rvalue" except in
passing in a footnote; the standard instead refers to the "value of an
expression", which is valid whether the expression happens to be an
lvalue or not. But that usage of "rvalue" is consistent with the
older meaning of "lvalue" (which someone, I don't remember who,
explained here recently). Namely, an lvalue and an rvalue are both
the result of evaluating an expression, but in different ways. An
rvalue is the result of evaluating an expression to determine an
ordinary value, such as 2+2 yielding 4. An lvalue, in this older
meaning, is the result of evaluating an expression to determine what
location it designates, such as *ptr yielding the memory location to
which ptr points (without regard to what may be currently stored in
that location). Subexpressions are evaluated for their rvalues or
their lvalues depending on the context in which they appear. If an
expression being evaluated for its lvalue doesn't currently designate
an object, the behavior is undefined.

The C standard dropped the term "rvalue" and changed the meaning of
"lvalue" so it refers to the expression itself, not to the result of
evaluating it in a particular way. In my opinion, the older usage was
more elegant; it may be a little harder to wrap you head around the
idea of evaluating something in two different ways, but it's a good
concept to have in your mental repertoire.

In my own view, even though an expression might refer to an object, it
becomes an lvalue only on the left of an assignment operator.

Consider:

int a, b, c; /* a, b and c are (refer to) objects */

a = 5; /* a is an lvalue */
b = a + 4; /* b is an lvalue, a is an rvalue and a + 4 is 9 */

That's a pretty good model too. It's a pity the standard isn't that
clear.