What exactly is lvalue & rvalue (old c.l.c. posts are all over the map)?

  • Thread starter Romeo Colacitti
  • Start date
R

Romeo Colacitti

Hi,

Does anyone here have a strong understanding for the meanings of the
terms "lvalue" and "rvalue" as it pertains to C, objects, and different
contexts? If so please share.

I've been reading several old posts/threads on the subject, and they
never end with a conclusion (people keep correcting each other and
disagreeing).

My take on it is that an "lvalue" is an expression that refers to an
object (which can have (a) value(s) within it), and "rvalue" is an
expression that only has a value (ephemeral value as Chris Torek would
claim) and no association with an object.

As far as their use, an "lvalue" that refers to an object of type T,
can be used anwhere an "rvalue" that that has a type T can be, but not
vice versa. So if one uses an lvalue that refers to an int variable in
an context that requires an int value, then simply the value sitting in
the object is dumped into that context.

Is this a fair description?
 
L

Luke Wu

Romeo said:
Hi,

Does anyone here have a strong understanding for the meanings of the
terms "lvalue" and "rvalue" as it pertains to C, objects, and different
contexts? If so please share.

I've been reading several old posts/threads on the subject, and they
never end with a conclusion (people keep correcting each other and
disagreeing).

My take on it is that an "lvalue" is an expression that refers to an
object (which can have (a) value(s) within it), and "rvalue" is an
expression that only has a value (ephemeral value as Chris Torek
points out) >and no association with an object.
As far as their use, an "lvalue" that refers to an object of type T,
can be used anwhere an "rvalue" that that has a type T can be, but not
vice versa. So if one uses an lvalue that refers to an int variable in
an context that requires an int value, then simply the value sitting in
the object is dumped into that context.

Is this a fair description?

Both "lvalue" and "(r)value" [current standards prefer to leave out the
'r' and insist that the 'l' means 'locator'] are expressions.

Some expressions are lvalues, while others are rvalues. By "are" I
mean, "evaluate to results that are." "Expression" need not be a full
expression but refers also to subexpressions too (even down to a
token-sequence for a variable name).

Every lvalue is converted to the corresponding (r)value represented in
it's object when used in a context that does not need an object
("value" context), EXCEPT for an lvalue referring to and array object
of type T (it is converted to an (r)value equal to the address of the
first element of the array and of type pointer to T).

When an lvalue is used in an "general object context," then the lvalue
is directly acted upon (no conversion to an rvalue takes place).
Examples are & and sizeof.

There is another special type of "object context" that requires not
only an lvalue, but a MODIFIABLE lvalue. These "special objects
contexts" include expressions involved with ++, --, and the left hand
sides of both = and op= . So only lvalues that are modifiable can be
used here, and they include all lvalues that are NOT: array names,
connected with objects declared as const, or connected with objects of
incomplete type (these are nonmodifiable lvalues).


All other contexts/operators (unless I missed some) require (r)values
as their expressions/operands. For example, arguments in function
calls are expected to be (r)value expressions (but we also lvalues
expressions, but they are automatically converted to the (r)values
represented by their associated objects).
[Another way to say this is, the function call arguments is of "value"
context]

Hope this helps.
 
P

pete

Romeo said:
Hi,

Does anyone here have a strong understanding for the meanings of the
terms "lvalue" and "rvalue" as it pertains to C, objects,
and different contexts? If so please share.

I've been reading several old posts/threads on the subject, and they
never end with a conclusion (people keep correcting each other and
disagreeing).

My take on it is that an "lvalue" is an expression that refers to an
object (which can have (a) value(s) within it), and "rvalue" is an
expression that only has a value (ephemeral value as Chris Torek would
claim) and no association with an object.

As far as their use, an "lvalue" that refers to an object of type T,
can be used anwhere an "rvalue" that that has a type T can be, but not
vice versa.
So if one uses an lvalue that refers to an int variable in
an context that requires an int value,
then simply the value sitting in
the object is dumped into that context.

Is this a fair description?

The lvalue, rvalue distinction
is something that can be determined at compile time.
If you have
int array[1];
then
array[-1] is an example of an lvalue which doesn't refer
to an object. The use of such an lvalue would be undefined behavior.
 
C

Chris Torek

The lvalue, rvalue distinction
is something that can be determined at compile time.

Well, in C99, maybe. :) The C89 definition says, in part, that
if one has a pointer of type "T *":

T *p;

then *p is an lvalue if and only if p actually points to an
object. Thus, in:

p = malloc(sizeof *p);
*p = some_T_value();

"*p" is an lvalue if malloc() succeeded, but not if it failed
(returned NULL).

This is of course a ridiculous situation, which is why the N869
draft wording says that *p is an lvalue in all cases -- even if
p==NULL for instance -- but that the effect is undefined if p does
not point to a valid object of type T.

Unfortunately, the C99 definition is apparently defective as well
(see past discussion here and in comp.std.c).

The terms date back to (at least) Algol, and the intent is clear
enough: lvalues occur on the left side of assignment operators,
and rvalues occur on the right -- hence the names "left value" and
"right value". In languages that lack C's profusion of operators,
a simple definition like this suffices; we write:

a := b;

and there is nothing like "b++" to clutter up the issue. C mixes
everything up into a wonderful, confusing jumble, and even
compiler-writers sometimes get it wrong. :)
If you have
int array[1];
then
array[-1] is an example of an lvalue which doesn't refer
to an object. The use of such an lvalue would be undefined behavior.

Again, apparently true in C99, but not (technically) in C89. But
this just means the C89 standard has a defect.
 
K

Kobu

Luke said:
When an lvalue is used in an "general object context," then the lvalue
is directly acted upon (no conversion to an rvalue takes place).
Examples are & and sizeof.

sizeof takes more than lvalues, consider...

sizeof(int *)
sizeof('A')
sizeof(33.029e-3LD)

so are types and constants objects too (note, size of directly taking
the objects as input above, not just lvalues that refer to the objects)


here is another example

sizeof("String Literal")

here, size is receiving only a pointer to the first element of the
string ('S'), so its equivalent to: sizeof(char *)

but that's not what we get, sizeof actually returns the size of the
whole string literal

I don't think sizeof fits cleanly with the theory of lvalues/rvalues.
 
C

Chris Torek

sizeof takes more than lvalues ...

Yes; and it also has more than one syntax:

sizeof expr
sizeof ( type-name )

An expression can, but need not, include outer parentheses; but
to use sizeof on a type-name you must use the parentheses.
consider...

sizeof(int *)

This one requires the parentheses.
sizeof('A')
sizeof(33.029e-3LD)

These two do not. (But "e-3LD" is syntactically wrong; I assume
you mean "e-3L", to make it a long-double constant.)
so are types and constants objects too (note, size of directly taking
the objects as input above, not just lvalues that refer to the objects)

No, but they *are* expressions.
here is another example

sizeof("String Literal")

here, size is receiving only a pointer to the first element of the
string ('S'), so its equivalent to: sizeof(char *)

but that's not what we get, sizeof actually returns the size of the
whole string literal

I don't think sizeof fits cleanly with the theory of lvalues/rvalues.

This is a more interesting case, because of an earlier comp.lang.c
discussion about string literals as initializers:

char s1[] = "this is OK";
char s2[] = ("but this is not");

A string literal -- which is a source code construct, rather than
something you might see at runtime -- can be used as an initializer
for an object of type "array N_opt of char", but if it is to be
used this way, it *must not* be enclosed in parentheses. A number
of compilers allow the parentheses anyway, no doubt because their
parsers have stripped them off by the time the partially-digested
token-sequence is delivered to the part of the compiler front-end
that finishes decorating the parse tree (adjusting types, adding
conversions where implied, and so on).

All of this is something of an aside, though, because given:

char buf[20];

we know that:

sizeof(buf) == sizeof buf

and both arguments to the equality operator are (size_t)20. The
implication here is that, although an array may be surrounded by
parentheses in an expression, it remains an array: it does not
undergo the "degeneration" or "decay", as some like to call it,
that converts "array N of T" to "pointer to T" merely because it
is parenthesized. (It merely happens that some compilers do this
parentheses-stripping a bit "overzealously", as it were, so that
the string-literal-as-initializer works even when a diagnostic is
required.)

The whole point of the "object context" vs "value context" that
Luke Wu brings up is to maintain, within the compiler's parse-tree
code, the notion of whether we want to convert array-objects to
pointer-values by computing &arr[0]. (In addition, we must also
remember whether we need to fetch the value of an ordinary object,
so that in:

int a = 3, b = 5;
... any (or no) code that does not change a or b ...
a = b;

we put the value/"rvalue" of b -- 5 -- into the ["lvalue"] object
a, rather than fetching a's previous value of 3, and trying to put
b's value into 3.) Inside the compiler, this context is generally
implicit: we know, based on the operator(s), whether we want to
find the actual *value* of "a" (3, in this case), or simply remember
the *name*:

=
/ \
a b

can be optimized to:

=
/ \
a 5

(because b is still known to be 5), but not to:

=
/ \
3 5

which is nonsensical. This property of "I want a value on the
right, but an object on the left" is associated with the ordinary
assignment operator "=".

Now, there *is* a significant difference between the sizeof and
assignment operators here, in that sizeof permits any expression
of any (legal) type *as well as* an object-name, while "=" demands
*only* an object-name ("lvalue") on the left: "3 = 5;" is an
error, but "sizeof 3" is OK.

All this means is that, in the part of the compiler that deals
with an "=" operator, we have:

/* assume "struct tree *tree" and tree->op is the op, tree->left
is the LHS and tree->right is the RHS, with tree->monad #defined
as either tree->left or tree->right for monadic (unary)
operators */

switch (tree->op) {
...
case ASSIGN:
if (!is_lvalue(tree->left))
error("assignment operator requires an lvalue");
tree->right = rvalue_convert(tree->right, get_typecode(tree->left));
/* rvalue_convert produces the error if the conversion is invalid */
break;

while in the code for "sizeof" we have:

case SIZEOF:
typecode = get_typecode(tree->monad);
if (is_incomplete_type(typecode)) /* includes sizeof(void) */
error("sizeof incomplete type");
if (is_function_type(typecode))
error("cannot take size of function");
tree->type = TYPE_SIZE_T;
tree->value = type_size(typecode) / type_size(TYPE_CHAR);
tree->is_constant = 1;
/* the division is to get the size in bytes rather than bits */

tree_releasenode(tree->monad); /* no longer needed */
break;

In other words, we do not need to *check* whether the argument to
sizeof is an object or a value, nor do we have to pass it into the
part of the compiler that extracts an rvalue from an lvalue (which
I called "rvalue_convert" here) if necessary, because all we care
about, in evaluating the "sizeof" operator, is the *type* of the
argument to sizeof. (This is no longer true in C99, where we have
to check whether the argument is a VLA and perhaps generate code
at runtime rather than just marking the result as "is a constant".
But C99 is a much more complicated language than C89.)
 
R

Romeo Colacitti

Chris said:
The lvalue, rvalue distinction
is something that can be determined at compile time.

Well, in C99, maybe. :) The C89 definition says, in part, that
if one has a pointer of type "T *":
snipping
If you have
int array[1];
then
array[-1] is an example of an lvalue which doesn't refer
to an object. The use of such an lvalue would be undefined behavior.

Again, apparently true in C99, but not (technically) in C89. But
this just means the C89 standard has a defect.

C99 is worse, because as per the said standard almost every expression
that doesn't resolve to an incomplete types or function type is an
LVALUE. So something like 2+3 is an lvalue in C99. I'll just modify
that errant sentence in the C99, it must obviously be a typo (they
forgot to mention that an lvalue "designates an object.")

Thanks for the help everyone.
 
L

Luke Wu

pete said:
/
Is this a fair description?

The lvalue, rvalue distinction
is something that can be determined at compile time.
If you have
int array[1];
then
array[-1] is an example of an lvalue which doesn't refer
to an object. The use of such an lvalue would be undefined behavior.

Yes, "lvalues" and "objects" are not the same thing.

An lvalues are just an expression (or the resolution of an expression)
that is of a form that can normally be used to designate objects (in
your case, array[-1] is of a form that is normally used to designate an
object, but this specific case is not referring to a valid object -
thus undefined behaviour).

Objects can also exist without lvalues . For example,

1)

char *ptr = "Hello";
ptr = NULL;

/* Hereafter the object "Hello" (an array) is lost in our abstract
machine
never to be referred to by an lvalue */

2)

malloc(100);

/* Hereafter the object allocated (100 bytes) is lost, never to be
referred to by an lvalue */




So objects and lvalues are different things.
 
B

Bart C

Romeo Colacitti said:
Hi,

Does anyone here have a strong understanding for the meanings of the
terms "lvalue" and "rvalue" as it pertains to C, objects, and different
contexts? If so please share.

I've been reading several old posts/threads on the subject, and they
never end with a conclusion (people keep correcting each other and
disagreeing).

I always thought an lvalue was something you could take the address of using
&.

So an assignment like:

a=b;

could be rewritten as:

*(&a)=b;

if a was a legal lvalue. If you can't then 'a' (whatever it might be) is not
an lvalue.

Bart
 
K

Kenneth Bull

Luke said:
snip


Yes, "lvalues" and "objects" are not the same thing.

An lvalues are just an expression (or the resolution of an expression)
that is of a form that can normally be used to designate objects (in
your case, array[-1] is of a form that is normally used to designate an
object, but this specific case is not referring to a valid object -
thus undefined behaviour).

Objects can also exist without lvalues . For example,

1)

char *ptr = "Hello";
ptr = NULL;

Even without reassigning ptr to NULL, there still can never exist an
lvalue that maps to the entire string literal object. The string
literal is an ANONYMOUS object. Pointers can only point to the
independent char object that make up the string literal aggregate array
(object).
/* Hereafter the object "Hello" (an array) is lost in our abstract
machine
never to be referred to by an lvalue */

2)

malloc(100);

The same applies here. Even if you did capture the return value of
malloc (void *) into a pointer with some sort of reference type, you
will still never get an lvalue that suggests the whole 100 byte object
on the heap (it's an ANONYMOUS object).

Although, you can capture the returned (void *) into a pointer to an
array of size equal to 100 bytes, but that is simply a useless case
(the pointer would serve no purpose).
/* Hereafter the object allocated (100 bytes) is lost, never to be
referred to by an lvalue */




So objects and lvalues are different things.

There are normal objects, and anonymous objects.
There are valid lvalues, and invalid lvalues.

Only the former from each sentence above can possibly be part of a
lvalue>object mapping.
 
C

Christian Bau

I always thought an lvalue was something you could take the address of using
&.

So an assignment like:

a=b;

could be rewritten as:

*(&a)=b;

if a was a legal lvalue. If you can't then 'a' (whatever it might be) is not
an lvalue.

Bitfields can be lvalues, but you can't take the address of a bitfield.
 
C

Christian Bau

Christian Bau said:
Bitfields can be lvalues, but you can't take the address of a bitfield.

And I forgot: Functions are most definitely not lvalues, but you can
take the address of a function.
 
I

Ivan A. Kosarev

Christian,
You wrote on Sun, 06 Feb 2005 22:53:25 +0000:
CB> And I forgot: Functions are most definitely not lvalues, but you can
CB> take the address of a function.

You also forgot that there are non-modifiable lvalues like those that are
const-qualified or that have incomplete types.
 
C

Christian Bau

"Ivan A. Kosarev said:
Christian,
You wrote on Sun, 06 Feb 2005 22:53:25 +0000:

-- Re-inserted original post here:
CB> And I forgot: Functions are most definitely not lvalues, but you can
CB> take the address of a function.

You also forgot that there are non-modifiable lvalues like those that are
const-qualified or that have incomplete types.

Looks like I didn't forget anything; you just snipped the part of the
original post that I answered to.
 
K

Kenneth Bull

Kobu said:
sizeof takes more than lvalues, consider...

sizeof(int *)
sizeof('A')
sizeof(33.029e-3LD)

so are types and constants objects too (note, size of directly taking
the objects as input above, not just lvalues that refer to the objects)


here is another example

sizeof("String Literal")

here, size is receiving only a pointer to the first element of the
string ('S'), so its equivalent to: sizeof(char *)

but that's not what we get, sizeof actually returns the size of the
whole string literal

I don't think sizeof fits cleanly with the theory of lvalues/rvalues.


Sizeof is an operator that can take two types of operands:

- types
- expressions(if lvalue expression, gives the size of the entire object
designated by the lvalue, if rvalue expression, gives the size of
object required to properly hold the rvalue)

When considering the sizeof(exp) syntax's behaviour, one might be
tempted to call this an example of an "object context." I argue that it
incorrect to say that sizeof(exp) is a case of "lvalue/object context."
Even though no lvalue-to-rvalue substitution takes plac for lvalue
expression, the fact that rvalues can be operands too should forbit us
from calling it an "object context." It is neither an "object context"
or a "value context", but rather a "makes no assumptions or
substitutions, operates directly on what you hand it CONTEXT"

This is why sizeof('A') works, not because 'A' is an lvalue or object
(constants are not objects).
 
K

Kenneth Brody

Romeo said:
Hi,

Does anyone here have a strong understanding for the meanings of the
terms "lvalue" and "rvalue" as it pertains to C, objects, and different
contexts? If so please share.
[...]

The simplest way to think of them would probably be:

An lvalue can go on the left of an assignment statement, and an
rvalue can go on the right. (Hence "l" and "r".)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:[email protected]>
 
B

Bart C

....
And I forgot: Functions are most definitely not lvalues, but you can
take the address of a function.

I think I'm still right apart from these two exceptions..

Bart
 
P

pete

Kenneth Bull wrote:
Sizeof is an operator that can take two types of operands:

- types
- expressions

The types must be object types
and the expressions must be expressions of object type.
 
P

pete

Christian said:
And I forgot: Functions are most definitely not lvalues, but you can
take the address of a function.

register qualified variables are lvalues without addresses.
 
R

Romeo Colacitti

Kenneth said:
There are normal objects, and anonymous objects.

A search for the term - anonymous - in the C standard came up with 0
results.

Explanation for malloc does say that it allocates AN OBJECT.
Explanation for calloc does say that it allocates AN ARRAY OF OBJECTS.
No mention of anonymous though.

I've come to the conclusion that the C language (and it's standard) has
so many exceptions, loopholes and gray areas that it's better to learn
and see all the cases than to try to understand the definitions and
rules within the standard.

I bet every C programmer has a different idea for what all these terms
mean, but all experts have seen all the cases/uses enough to understand
things deep enough not to care for exact definitions. Such a
frustrating language, but I can't live without it :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,906
Latest member
SkinfixSkintag

Latest Threads

Top