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

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?

0
wwromeo (17)
2/6/2005 5:07:47 AM
comp.lang.c 29960 articles. 1 followers. spinoza1111 (3247) is leader. Post Follow

24 Replies
155 Views

Similar Articles

[PageSpeed] 17
Romeo Colacitti wrote:
> 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.

0
2/6/2005 5:48:23 AM
Romeo Colacitti wrote:
> 
> 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.

-- 
pete
0
pfiland (6614)
2/6/2005 6:46:51 AM
In article <4205BD5C.6DC8@mindspring.com>
pete  <pfiland@mindspring.com> wrote:
>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.
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
0
nospam252 (1722)
2/6/2005 8:19:12 AM
Luke Wu wrote:
>
> 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.

0
kobu.selva (53)
2/6/2005 5:04:38 PM
>Luke Wu wrote:
>> 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.

In article <1107709477.995487.296710@f14g2000cwb.googlegroups.com>
Kobu <kobu.selva@gmail.com> wrote:
>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.)
-- 
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W)  +1 801 277 2603
email: forget about it   http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
0
nospam252 (1722)
2/6/2005 6:47:58 PM
Chris Torek wrote:
> In article <4205BD5C.6DC8@mindspring.com>
> pete  <pfiland@mindspring.com> wrote:
> >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.

0
wwromeo (17)
2/6/2005 8:05:48 PM
pete wrote:
> Romeo Colacitti wrote:
> >

/

> >
> > 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.

0
2/6/2005 10:08:02 PM
"Romeo Colacitti" <wwromeo@gmail.com> wrote in message
news:1107666467.021755.326460@c13g2000cwb.googlegroups.com...
> 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



0
bc (2337)
2/6/2005 10:37:11 PM
Luke Wu wrote:
>

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.

0
2/6/2005 10:40:48 PM
In article <42069c1e@212.67.96.135>, "Bart C" <bc@freeuk.com> wrote:

> "Romeo Colacitti" <wwromeo@gmail.com> wrote in message
> news:1107666467.021755.326460@c13g2000cwb.googlegroups.com...
> > 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.

Bitfields can be lvalues, but you can't take the address of a bitfield.
0
2/6/2005 10:52:15 PM
In article 
<christian.bau-0CD778.22521506022005@slb-newsm1.svr.pol.co.uk>,
 Christian Bau <christian.bau@cbau.freeserve.co.uk> wrote:

> In article <42069c1e@212.67.96.135>, "Bart C" <bc@freeuk.com> wrote:
> 
> > "Romeo Colacitti" <wwromeo@gmail.com> wrote in message
> > news:1107666467.021755.326460@c13g2000cwb.googlegroups.com...
> > > 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.
> 
> 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.
0
2/6/2005 10:53:25 PM
Christian,
You wrote  on Sun, 06 Feb 2005 22:53:25 +0000:

>> > 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.
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.

--
Ivan

Unicals Group -- Your own commercial high-quality C99 front end for US $1
http://unicals.com/own-business.html


0
ikosarev (15)
2/6/2005 11:29:00 PM
In article <36nnhvF50s0mnU1@individual.net>,
 "Ivan A. Kosarev" <ikosarev@online.ru> wrote:

> Christian,
> You wrote  on Sun, 06 Feb 2005 22:53:25 +0000:
> 

-- Re-inserted original post here: 
> > "Romeo Colacitti" <wwromeo@gmail.com> wrote in message
> > news:1107666467.021755.326460@c13g2000cwb.googlegroups.com...
> > > 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
> > &.
> > 
-- End of re-inserted original post
> >> > 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.
> 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.
0
2/6/2005 11:40:20 PM
Kobu wrote:
> Luke Wu wrote:
> >
> > 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.


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).

0
2/6/2005 11:41:38 PM
Romeo Colacitti wrote:
> 
> 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:ThisIsASpamTrap@gmail.com>

0
kenbrody (1879)
2/6/2005 11:47:04 PM
"Christian Bau" <christian.bau@cbau.freeserve.co.uk> wrote in message 
news:christian.bau-31BAE1.22532506022005@slb-newsm1.svr.pol.co.uk...
....
>> In article <42069c1e@212.67.96.135>, "Bart C" <bc@freeuk.com> wrote:
>> > I always thought an lvalue was something you could take the address of 
>> > using
>> > &.
....
>> 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 think I'm still right apart from these two exceptions..

Bart



0
bc (2337)
2/7/2005 12:47:16 AM
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.

-- 
pete
0
pfiland (6614)
2/7/2005 1:16:48 AM
Christian Bau wrote:
> 
> In article
> <christian.bau-0CD778.22521506022005@slb-newsm1.svr.pol.co.uk>,
>  Christian Bau <christian.bau@cbau.freeserve.co.uk> wrote:
> 
> > In article <42069c1e@212.67.96.135>, "Bart C" <bc@freeuk.com> wrote:
> >
> > > "Romeo Colacitti" <wwromeo@gmail.com> wrote in message
> > > news:1107666467.021755.326460@c13g2000cwb.googlegroups.com...
> > > > 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.
> >
> > 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.

register qualified variables are lvalues without addresses.

-- 
pete
0
pfiland (6614)
2/7/2005 1:21:52 AM
Kenneth Bull wrote:
>
> 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 :-)

0
wwromeo (17)
2/7/2005 5:27:18 AM
On Sun, 06 Feb 2005 14:08:02 -0800, Luke Wu wrote:

....

> 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 */

The string literal itself i.e. the "Hello" in the source code is an lvalue.

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

True, but not very interesting or useful.

> So objects and lvalues are different things.

lvalues exist in the source code, objects exist in the execution
environment.

Lawrence
0
lknews (877)
2/7/2005 11:27:51 AM
On Sun, 06 Feb 2005 09:04:38 -0800, Kobu wrote:

> 
> Luke Wu wrote:
>>
>> 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 *)

Why do you assume that to start with? Note that while you are using a
string literal here, it is just an example of an array lvalue.

> 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 unique because it doesn't evaluate its operand (as a value or an
lvalue); all sizeof cares about is the type of the operand. With C99 VLAs
determining the operand type can require a calculation based on runtime
information but it still isn't accessing the value or lvalue of the
operand (and obviously not if the operand is specifically a type).

Lawrence

0
lknews (877)
2/7/2005 11:45:09 AM
"Romeo Colacitti" <wwromeo@gmail.com> writes:
> Chris Torek wrote:
>> In article <4205BD5C.6DC8@mindspring.com>
>> pete  <pfiland@mindspring.com> wrote:
[...]
>> >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.")

Alas, it wasn't a typo.  In C90, an lvalue is defined as "an
expression (with an object type or an incomplete type other than void)
that designates an object".  The flaw in this definition, given
    int *ptr;
the expression *ptr may or may not designate an object (it doesn't of
ptr==NULL, for example).  So strictly speaking, you can't always
determine whether an expression is an lvalue until runtime, which
clearly was not the intent.

C99 attempted to correct this by dropping the absolute requirement
that an lvalue must designate an object; an lvalue is now "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."  Strictly speaking, 42 is an lvalue (it's an
expression with an object type) -- and evaluating it invokes undefined
behavior.  Again, this clearly was not the intent.

An lvalue *should* be defined as an expression that *potentially*
designates an object.  For example, *ptr is an lvalue regardless of
the value of ptr, and evaluating *ptr invokes undefined behavior if it
doesn't currently designate an object.  The expression 42 is not an
lvalue.  The problem, I suppose, is expressing this in standardese,
but IMHO correctness is more important than rigor here.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.
0
kst-u (21963)
2/7/2005 9:28:30 PM
Keith Thompson wrote:
>
> An lvalue *should* be defined as an expression that *potentially*
> designates an object.  For example, *ptr is an lvalue regardless of
> the value of ptr, and evaluating *ptr invokes undefined behavior if
it
> doesn't currently designate an object.  The expression 42 is not an
> lvalue.  The problem, I suppose, is expressing this in standardese,
> but IMHO correctness is more important than rigor here.
>

Or they could just list all possible types of lvalues in a short
passage (there aren't many).  They would have to define it according to
the final result of expressions (what they evaluate to), which is what
they mean by "expressions" in the current standard anyway.

0
2/8/2005 10:02:26 PM
Lawrence Kirby wrote:

> sizeof is unique because it doesn't evaluate its operand (as a value
or an
> lvalue); all sizeof cares about is the type of the operand. With C99
VLAs
> determining the operand type can require a calculation based on
runtime
> information but it still isn't accessing the value or lvalue of the
> operand (and obviously not if the operand is specifically a type).
>
> Lawrence

Which is why people shouldn't call sizeof an "object context" or
"lvalue context"

0
2/8/2005 10:07:52 PM
Reply:
Similar Artilces:

ActiveSync post-sync step
Hello, I remember I read once somewhere that a post-sync "action" might be possible. So the basic ideea is that after the synchronisation process is over you could execute an external application or something like this. If you happend to know anything about this please give any hint .. it would be apreciated very much. thanx in advance. Ioan-Paul Pirau. ...

An exact simplification challenge
Hello, MeijerG[{{0}, {1}}, {{0, 0, 0, 1/2}, {}}, 1/4] ? Best wishes, Vladimir Bondarenko Co-founder, CEO, Mathematical Director http://www.cybertester.com/ Cyber Tester, LLC ------------------------------------------------------- "We must understand that technologies like these are the way of the future." ------------------------------------------------------- On 31 Jul., 21:24, Vladimir Bondarenko <v...@cybertester.com> wrote: > MeijerG[{{0}, {1}}, {{0, 0, 0, 1/2}, {}}, 1/4] Here's what I entered in Maple: c...

Vanilla ANSI C headers wanted
I'm working on this compiler/libc suite. It's a bit antiquated and the headers badly need reworking to be brought up to date and to separate out the platform-specific stuff from the platform-independent stuff. Does anyone know where I can find a set of minimal ANSI headers that I can use as a reference? (I'm also wanting Posix, too, but that can wait for now. As well as being off-topic.) My usual source for this kind of thing --- the C development kit for the BSD operating systems --- isn't really terribly useful because the ANSI, Posix and platform-specific headers ar...

US-TX-Austin: Lead SW Engineer, C++, CORBA, Voice packetization/Voice codecs; C- (45302157605)
US-TX-Austin: Lead SW Engineer, C++, CORBA, Voice packetization/Voice codecs; C- (45302157605) ============================================================================================== Position: Lead SW Engineer Reference: SMC01407 Location: Austin TX Duration: C-P Skills: BSEE or BSCS 7+yrs software design/implementation experience Ability to work well with others in a team environment Strong written and verbal communication skills Superior problem solving skills Knowledge of pattern-oriented sof...

Re: Subj: OT: Re: [HP3000-L] 60 OT: re Minutes
Or as Jay Leno said last night, CBS' "60 Minutes" now refers to how much time they spend authenticating their sources!! John Lee At 09:53 PM 9/13/04 -0500, Denys Beauchemin wrote: >So, another one that supports the predominant belief the documents are >fake. > >On the other hand, the only thing CBS has to do to prove the validity of >these memos is to give the originals to a panel of experts for analysis. > > >It would also be helpful if they could give us some indication as to >where these memos come from. They do not have to name na...

grep exact PID
Hi, I'm trying to grep a PID (eg 1234) currently i'm ps -ef grep 1234 |awk '{print $2}' |wc to make sure that i'm grepping the exact 1234 (4 digit PID) and not 12345. Is there more elagant and efficient way of grepping the PID, 1234? Thanks and regards Smith wrote: > Hi, > I'm trying to grep a PID (eg 1234) > currently i'm ps -ef grep 1234 |awk '{print $2}' |wc to make sure that i'm > grepping the exact 1234 (4 digit PID) and not 12345. > > Is there more elagant and efficient way of grepping the PID, 1234? no need to use grep, u...

US-TX-San Antonio: SysAdmin/Spt Tech, Exp w office tracker, Helix and email, c-p (45319232408)
US-TX-San Antonio: SysAdmin/Spt Tech, Exp w office tracker, Helix and email, c-p (45319232408) ============================================================================================== Position: SysAdmin/Spt Tech Reference: SMC01579 Location: San Antonio TX Duration: Contract to Full Time Skills: Exp with office tracker, helix and email Exp. troubleshooting HW problems Exp. with word processing, spreadsheet and email software Developmental skills a plus Scope: Troubleshoot software problems (office track...

Old Amiga stuff -- free
had no idea that Amiga wasn't completely dead, so I sold my A1000 cheap. But I still have software and books. I promised them to the guy that bought the hardware, but I lost his address, and he doesn't answer e-mails. SO, if someone wants to pick this stuff up in Fort Wayne, Indiana (or send a local friend to pick it up), just speak up. It's really not worth shipping, IMHO. -- Wes Groleau Alive and Well http://freepages.religions.rootsweb.com/~wgroleau/ ...

===Welcome to comp.lang.c++! Read this first. #417
Welcome to comp.lang.c++! Read this first. This post is intended to give the new reader an introduction to reading and posting in this newsgroup. We respectfully request that you read all the way through this post, as it helps make for a more pleasant and useful group for everyone. First of all, please keep in mind that comp.lang.c++ is a group for discussion of general issues of the C++ programming language, as defined by the ANSI/ISO language standard. If you have a problem that is specific to a particular system or compiler, you are much more likely to get complete and accurate answers in...

Proc FREQ ; exact pchi;
Dear colleagues, A SAS sample program displaying the features of the Proc FREQ includes a statement exact pchi. Pchi means Pearson chi square. This makes me confused because, as far as I know, the pearson chi- square is not the exact test but the asymptotic one. Any suggestion ? Here is the sample: "Analyzing a 2=D72 Contingency Table" options nodate pageno=3D1 linesize=3D84 pagesize=3D64; proc format; value expfmt 1=3D'High Cholesterol Diet' 0=3D'Low Cholesterol Diet'; value rspfmt 1=3D'Yes' 0=3D'No'; ru...

US-TX-Austin: HardwareSoftware Eng, C, C++ , Microsoft OS, Logic Analyzer, Scope (45358114403)
US-TX-Austin: HardwareSoftware Eng, C, C++ , Microsoft OS, Logic Analyzer, Scope (45358114403) ============================================================================================== Position: HardwareSoftware Eng Reference: ZYD00153 Location: Austin TX Duration: Skills: Knowledge in C and C++ ,Microsoft OS Possess a healthy paranoia about bugs along with a strong vision for continuous validation improvements Prior use of Embedded SW (software) Development Methodology A team player with good organizat...

c pointers
i really am having big trouble with c pointers. anyone wanna encourage me? my e-mail is real...i use it too. mitchellpal@gmail.com wrote: > i really am having big trouble with c pointers. anyone wanna encourage > me? my e-mail is real...i use it too. > Go on mate! Read that C textbook on your bookshelf! Reading a few c.l.c threads on the subject will help, too. Was this good? If you have a specific question though, do come back here. Cheers Vladimir PS My e-mail is real as well, but I don't use it for private lessons, especially not free ones. -- My e-mail address is r...

New and enhanced low cost C compilers
Low Cost C Compilers ------------------------------------ HI-TECH Software's C compilers are now available to support the ARM, dsPIC, msp430, 8051, PIC 10 to 17, PIC 18 as well as many other popular 8/16/32 bit micros. Recent releases of these compilers have included significant enhancements to aid development and debugging. ARM - includes a USB based JTAG interface with high level debug software dsPIC - fully integrates with MPLAB msp430 - High level debugging with JTAG cables PIC-18 - Code & I/O simulation, integrates with MPLAB 8051 - Code & ...

How to write to a file including directory name in C?
Dear all: I am trying to write to a file with full directory name and file name specified (./outdir/mytestout.txt where . is the current directory) in C programming language and under Unix, but got errors of Failed to open file ./outdir/mytestout.txt. Below is the code: #include <stdio.h> int main(void) { FILE *fp; char fname[30]; char pathname[30]; strcpy(fname,"./outdir/mytestout.txt"); fp=fopen(fname, "w"); if (fp == NULL) { printf("Failed to open file %s\n", fname); } else { fprintf(fp, "This is just a t...

Biped C.O.M Problem... Urgent
Hi, my apologies for the cross post, but this sadly for me, is urgent :( I Hope sometime can help� I've created a new character studio biped in my scene, but I can't move the Centre of Mass (COM) in either Figure mode, or out of figure mode using the move tools (Body Vertical, Body Horizontal, and Body Rotation.) I'm not in key framing / animating mode either. I can pose the arms, legs, and such, I can also scale the parts of the biped etc, but I cannot seem to move the C.O.M at all. Stats: Windows 2000 SP4 -- 3dsMax 5.0 -- Character Studio 3.4 (all fully aut...

US-TX-Austin: Windows GUI, C#, .NET, Win-Forms, ADO. (45351657605)
US-TX-Austin: Windows GUI, C#, .NET, Win-Forms, ADO. (45351657605) ================================================================== Position: Windows GUI Applications Developer Reference: MLS00006 Location: Austin TX Duration: 6mo - pos perm Skills: C#, .NET, Win-Forms, ADO.NET Additional Consideration For: Protocol Analyzer experience, PCI-Express knowledge, or MCSD/MCAD certification Scope: Win-Forms based experience as well as custom control development experience. Additionally, this position ...

Approximate vs Exact
Hi it's me again. I have question regarding approximate and exact mode. I have an expression, say 4*sqrt(7)*x. Is there a way I can quickly switch it to 10.5830052442*x. I know I can't use num() function. So far I figure the only way is to re-enter the answer after switching to approximate. Is there a more convenient way to make the switch like in TI-89? Or is there a shortcut combo for switching modes from exact to approximate and back? Thank you. Toggle to approx mode (RS-hold-ENTER), press EVAL, and toggle back to exact mode if desired. Normal flag settings are assumed. -...

ANN: c.l.c FAQ in need of a good home
I'm looking for a good home for the comp.lang.clipper FAQ. Note, the *FAQ*, not the *VFAQ* (although I'd be happy to hand that over to a new home too -- more on that later). Back around 1998 it was decided that, because Mark Schumann was increasingly busy with other things, maintenance of the FAQ might be best passed on to someone with more time on their hands. Given that I had the right tools in place to build and maintain the FAQ I took over main responsibility and attempted to build up a core of maintainers. A mailing list was put in place and a couple or so interested people joine...

rdataset.c:652: REQUIRE(dbp != ((void *)0) && *dbp == ((void *)0)) failed
We have had a failure of one of our BIND installations this morning. The failure happened at 01:51:45 BST on a machine that was effectively idle at the time. The previous messages logged by 'named' were 30 seconds before the crash and were a zone transfer from a Microsoft 2003 DNS server of an AD integrated zone. I can provide config files if they are useful. The version of BIND is a stock build from Fedora 9 - bind-9.5.1-2.P2.fc9.i386. Is this a known problem, should we upgrade to get away from it, any advice? Regards, HOward. _______________________________...

US-TX-Austin: X86 DV Engineer, X86 programming exp., C/C++, Assembly; Perm (45339559782)
US-TX-Austin: X86 DV Engineer, X86 programming exp., C/C++, Assembly; Perm (45339559782) ======================================================================================== Position: X86 DV Engineer Reference: SMC01831 Location: Austin TX Duration: Perm Skills: Requires recent, extensive expertise in x86 programming. Requires strong C/C++ and assembly language skills. Highly motivated self-starter. Excellent verbal/written communication skills. Experience with writing device drivers for any environment ...

Does Common Lisp have a C interface?
Hello, I am not a lisper - and just curious about the language, because it comes with quite a few concepts that are really nice... But one question, because this would be a knockout criteria for me to dive deeper into Lisp (if I had the time and need for that diving): Does CL or one of it's implementations have a C interface, so that one could integrate number crunching libraries and other neat stuff that is written in C? Thanks in advance E. On Fri, 18 Jan 2008 12:38:03 +0100, EL <eckhardnospam@gmx.de> wrote: > But one question, because this would be a knockout criteria f...

US-GA-Atlanta/Alpharetta: Senior C++ Developer Wanted
The Embedded Products Group of Scientific Games is seeking senior level C++ developers for a permanent position(s) in Alpharetta, Georgia. Critical requirements are strong C++ skills, experience in object-oriented design and implementation of such designs in C++, usage of C++ as an object oriented language (not a better C) and common idioms. If you don't know what this means then you shouldn't apply for this position. On a scale of 1 to 5 you should rate a minimum of 3.75 to even bother submitting a resume. This means you COMMONLY use all major features of the C++ language and ...

Post of the Year 2006
Congratulations to Olivier Paquet, winner of the RenderMan newsgroup "Post of the Year" award for 2006. His explanation of several pitfalls of occlusion culling was judged to be the most helpful to someone writing a renderer of all the articles posted on this newsgroup last year. See Olivier's winning article along with those of past winners at: http://www.dotcsw.com/links.html#forums Although it may seem like Olivier has won two years in a row, the award last year actually went to Matthias Baas for the question to which Olivier provided a concise answer. R...

how to remove old package in Redhat 9.0
Hi, I have installed the server and started up successfully. mysql.sock file is written to /var/lib/mysql/ directory as well. Now I found that I also need to install mysql 4.10-1 client. However there is already mysql3 installed in the system. How can I remove the old version in Redhat? Here are all error I got: # rpm -i MySQL-client-4.1.10-0.i386.rpm warning: MySQL-client-4.1.10-0.i386.rpm: V3 DSA signature: NOKEY, key ID 5072e1f5 file /usr/bin/mysql from install of MySQL-client-4.1.10-0 conflicts with file from package mysql-3.23.54a-11 file /usr/bin/mysql_find_rows f...

US-TX-Austin: RF Application Eng, Analog/Digital design, Mixed signal bckgrnd, C (45315032405)
US-TX-Austin: RF Application Eng, Analog/Digital design, Mixed signal bckgrnd, C (45315032405) ============================================================================================== Position: RF Application Eng Reference: SMC01504 Location: Austin TX Duration: C-P Skills: MSEE or BSEE plus 5 years RF design/product experience. 0-5 years RF design/product experience. Design experience with analog and digital modulation schemes (AMPS, GSM, TDMA, CDMA) a plus. Strong mixed-signal background. ...