assignment
srinivas reddy
" the r-value of targ after executing assignment targ = source; is
equal to the r-value of source before executing the command".
Is this statement conforms to what the standard says? If not I would
appreciate if anybody provides the reason also.
Srinivas Reddy.
Mike Wahler
news:ff8ef364.02012...@posting.google.com...
> Recently I came across this statement:
> " the r-value of targ after executing assignment targ = source; is
> equal to the r-value of source before executing the command".
> Is this statement conforms to what the standard says?
I don't think it 'conforms' to anything. For the statement:
targ = source;
to be valid, 'targ' must be an lvalue, and 'source'
can be either an rvalue or an lvalue.
> If not I would
> appreciate if anybody provides the reason also.
It can be stated much more simply:
The value of 'targ' after the assignment will be
the same as that of 'source'.
Objects don't *have* 'rvalues', they might or might
not *be* 'r-values'. Every object has a value.
BTW where did you read that convoluted (and technically
inaccurate -- e.g. there are no 'commands' in C) statement?
-Mike
pete
>
> srinivas reddy <sriniva...@yahoo.com> wrote in message
> news:ff8ef364.02012...@posting.google.com...
> > Recently I came across this statement:
> > " the r-value of targ after executing assignment targ = source; is
> > equal to the r-value of source before executing the command".
> > Is this statement conforms to what the standard says?
>
> I don't think it 'conforms' to anything. For the statement:
>
> targ = source;
>
> to be valid, 'targ' must be an lvalue, and 'source'
> can be either an rvalue or an lvalue.
>
> > If not I would
> > appreciate if anybody provides the reason also.
>
> It can be stated much more simply:
>
> The value of 'targ' after the assignment will be
> the same as that of 'source'.
>
> Objects don't *have* 'rvalues', they might or might
> not *be* 'r-values'. Every object has a value.
Expressions don't *have* 'rvalues', they might or might
not *be* 'r-values'. Every object is an lvalue.
All other expressions are rvalues.
K&R2
"An object is a named region of storage; an lvalue is an expression
refering to an object."
--
pete
William D. Tallman
Ummm... what is an expression? I thought an expression was a statement,
often algebraic (containing an operator), but not necessarily. "An object
is a named region of storage..." (hunk of RAM real-estate with a tag...),
"..an lvalue is an expression refering to an object." (name on the tag...).
So every object *has* an lvalue, and can be assigned an rvalue (data in RAM
hunk...). Thus: <describef("%object %lvalue %rvalue",
acreage_in_RAMland, title_to_acreage, who/what_lives_there);> Did I get
that right?
Bill Tallman
Ben Pfaff
> pete wrote:
>
> > K&R2
> > "An object is a named region of storage; an lvalue is an expression
> > refering to an object."
> >
> Ummm... what is an expression? I thought an expression was a
> statement,
An expression can be used as a statement in itself, if followed
by a semicolon, but needn't be. Expressions can also be part of
larger statements (such as the up to three expressions that are
part of the for statement) or declarations (as an array size).
> often algebraic (containing an operator), but not necessarily. "An object
> is a named region of storage..." (hunk of RAM real-estate with a tag...),
> "..an lvalue is an expression refering to an object." (name on the tag...).
>
> So every object *has* an lvalue, and can be assigned an rvalue (data in RAM
> hunk...). Thus: <describef("%object %lvalue %rvalue",
> acreage_in_RAMland, title_to_acreage, who/what_lives_there);>
I followed you up to the funny notation with angle brackets and
percent signs.
Joe Wright
>
[snip]
> Expressions don't *have* 'rvalues', they might or might
> not *be* 'r-values'. Every object is an lvalue.
> All other expressions are rvalues.
>
> K&R2
> "An object is a named region of storage; an lvalue is an expression
> refering to an object."
>
nicely to the left of an assignment operator. The term rvalue is a
catchall for values not an lvalue.
--
Joe Wright mailto:joeww...@earthlink.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
William D. Tallman
> An expression can be used as a statement in itself, if followed
> by a semicolon, but needn't be. Expressions can also be part of
> larger statements (such as the up to three expressions that are
> part of the for statement) or declarations (as an array size).
Aha! I was over-formalizing the concept.
>> often algebraic (containing an operator), but not necessarily. "An
>> object is a named region of storage..." (hunk of RAM real-estate with a
>> tag...),
>> "..an lvalue is an expression refering to an object." (name on the
>> tag...).
>>
>> So every object *has* an lvalue, and can be assigned an rvalue (data in
>> RAM
>> hunk...). Thus: <describef("%object %lvalue %rvalue",
>> acreage_in_RAMland, title_to_acreage, who/what_lives_there);>
>
> I followed you up to the funny notation with angle brackets and
> percent signs.
LOL!!!!!!!!!
New language (C derivative) called "C@". Defines stuff like
do_what_I_mean() and the like. Read-only replacement for Pascal for
non-programmers. The carets indicate it's cadet relationship with other
code genre...
Off topic here, of course..... <grin>
But thanks for the explanation!
Bill Tallman
Mike Wahler
Joe Wright <joeww...@earthlink.net> wrote in message
news:3C5894...@earthlink.net...
> pete wrote:
> >
> [snip]
> > Expressions don't *have* 'rvalues', they might or might
> > not *be* 'r-values'. Every object is an lvalue.
> > All other expressions are rvalues.
> >
> > K&R2
> > "An object is a named region of storage; an lvalue is an expression
> > refering to an object."
> >
> Classically (K&R), an lvalue is the result of an expression that fits
> nicely to the left of an assignment operator. The term rvalue is a
> catchall for values not an lvalue.
lvalues can be modifiable or not.
-Mike
pete
K&R2 A7
"Primary expressions are identifiers, constants, strings
or epressions in parentheses."
K&R2 A9
"Most statements are expression statements, ... "
Statements don't have values, while expressions do.
> So every object *has* an lvalue,
Every object *is* an lvalue.
The value of either an rvalue or an lvalue,
can be assigned to an lvalue.
An rvalue is an expression like (4 + 2)
You can't access the memory location wich holds that
value and write to it.
Are you ever going to write a line of code like this? :
(4 + 2) = x;
--
pete
Pai-Yi HSIAO
> Every object *is* an lvalue.
3.15
[#1] object
region of data storage in the execution environment, the
contents of which can represent values
6.3.2.1 Lvalues and function designators
[#1] An lvalue is an expression with an object type or an
incomplete type other than void;46) if an lvalue does not
designate an object when it is evaluated, the behavior is
undefined.
6.5 Expressions
[#1] An expression is a sequence of operators and operands
that specifies computation of a value, or that designates an
object or a function, or that generates side effects, or
that performs a combination thereof.
I'm confussed by the above clauses.
For example,
int i;
i=0;
According to 6.3.2.1[#1] and 6.5[#1],
the expression 'i=0;' has type int and hence is an lvalue.
(This is contradictory to 6.5.16[#3], saying, an assignment expression
is not an lvalue.)
Also according to 6.3.2.1[#1], I can not see how to give a plausibe
explanation to say the object 'i' is an lvalue.
paiyi
William D. Tallman
> William D. Tallman wrote:
[snip]
>> So every object *has* an lvalue,
> Every object *is* an lvalue.
What I get from your assertion is that the C language is comprised only of
statements of some sort. If so, anything that exists within that language
must at least be a statement. And since expressions are statements, then
everything contained therein is likely to be (by definition?) an expression
as well.
Thus, an object is an expression and is by definition an lvalue.
Did I get that right? (Newbie is concerned here....)
Bill Tallman
Pai-Yi HSIAO
> pete wrote:
> > Every object *is* an lvalue.
>
Right.
Moreover, an expression like "(int) (10+2)" is ALSO an lvalue according
to the standard although it doesn't designate an object.
paiyi
Jeremy Yallop
| Thus, an object is an expression and is by definition an lvalue.
No, an object (in C) is a region of storage (memory), certainly not an
expression[0]. An lvalue _is_ an expression that designates an
object[1] - some kind of label that refers to the bytes which make up
the object. So the declaration
int i;
sets aside a region of storage (the object) that can be referred to by
the identifier 'i' (an lvalue). There may be other lvalues that refer
to the same object - for instance, if we declare a pointer to i:
int *p = &i;
we now have two ways of referring to the same object - two lvalues
('*p' and 'i').
Lvalues are often thought of as 'anything that can appear on the left
side of an assignment expression', which is so easy to understand that
it's a shame that it's wrong (think of array names, and objects with
const-qualified types). Since it's useful to have a name for such
things the C89 standard introduced the idea of a 'modifiable lvalue',
which does fit this simple definition.
Jeremy.
[0] 'Expression' is such a wide-reaching term that it's easiest just
to give the standard's definition:
[#1] An expression is a sequence of operators and operands that
specifies computation of a value, or that designates an object or a
function, or that generates side effects, or that performs a
combination thereof.
[1] In C89, that is. In C99 an lvalue is an 'expression with an
object type' that may or may not refer to an object. This avoids
the question 'does *p designate a valid object?', which can't, in
general, be answered at translation-time, making it impossible to
decide (in C89) whether a given expression is an lvalue. However,
it seems that the C99 definition has introduced far deeper
problems: see
http://groups.google.com/groups?hl=en&th=f088418bcacb826d
for an interesting discussion.
William D. Tallman
> * William D. Tallman
> | Thus, an object is an expression and is by definition an lvalue.
>
> No, an object (in C) is a region of storage (memory), certainly not an
> expression[0]. An lvalue _is_ an expression that designates an
> object[1] - some kind of label that refers to the bytes which make up
> the object. So the declaration
>
> int i;
>
> sets aside a region of storage (the object) that can be referred to by
> the identifier 'i' (an lvalue). There may be other lvalues that refer
> to the same object - for instance, if we declare a pointer to i:
>
> int *p = &i;
>
> we now have two ways of referring to the same object - two lvalues
> ('*p' and 'i').
>
> Lvalues are often thought of as 'anything that can appear on the left
> side of an assignment expression', which is so easy to understand that
> it's a shame that it's wrong (think of array names, and objects with
> const-qualified types). Since it's useful to have a name for such
> things the C89 standard introduced the idea of a 'modifiable lvalue',
> which does fit this simple definition.
>
> Jeremy.
Well, your explanation agrees with my understanding, but does not agree (?)
with Pete's. He said that an object *is* an lvalue, where I said that an
object *has* an lvalue, that an object and an lvalue weren't the same thing.
I was reaching for a plausible explanation for his argument.... and
apparently missed (?)
I could have quoted the standards to support my statements, but didn't as
it appears they can be interpreted broadly enough to produce conflicting
views.
I think I'll presume that my original understanding was adequate.
Thanks,
Bill Tallman
pete
>
> On Thu, 31 Jan 2002, pete wrote:
> > Every object *is* an lvalue.
> > The value of either an rvalue or an lvalue can be assigned to an lvalue.
>
> 3.15
> [#1] object
> region of data storage in the execution environment, the
> contents of which can represent values
>
> 6.3.2.1 Lvalues and function designators
> [#1] An lvalue is an expression with an object type or an
> incomplete type other than void;46) if an lvalue does not
> designate an object when it is evaluated, the behavior is
> undefined.
int i;
i is an lvalue which *does* designate an object when evaluated.
*(&i + 1), is an lvalue which *does not* designate an object when
evaluated.
(*(&i + 1) = 5), won't generate a compiler warning, but it's undefined.
*(&i + 1) is an lvalue, 5 is an rvalue.
(5 = *(&i + 1)), won't compile.
> 6.5 Expressions
> [#1] An expression is a sequence of operators and operands
> that specifies computation of a value, or that designates an
> object or a function, or that generates side effects, or
> that performs a combination thereof.
>
> I'm confussed by the above clauses.
>
> For example,
> int i;
> i=0;
>
> According to 6.3.2.1[#1] and 6.5[#1],
> the expression 'i=0;' has type int and hence is an lvalue.
(i=0) is an expression.
i=0; is a statment.
The kind of statement that i=0; is, is an "expression statement".
(i=0) has a value, it is an expression.
(i=0) does not have an address, &(i=0) is meaningless, therefore
(i=0) is an rvalue, but not a variable.
You can wrap an expression in extra parentheses.
(((i=0)))
x = (i=0); assigns the value of an rvalue(i=0), to an lvalue(X)
You can't wrap a statement in parentheses, x = (i=0;)
Even though you can't access the address of a register variable,
it is still "a named region of storage", which you can read
and write data to, so registers are lvalues too.
>
> (This is contradictory to 6.5.16[#3], saying, an assignment expression
> is not an lvalue.)
>
> Also according to 6.3.2.1[#1], I can not see how to give a plausibe
> explanation to say the object 'i' is an lvalue.
>
> paiyi
--
pete
pete
>
> Jeremy Yallop wrote:
>
> > * William D. Tallman
> > | Thus, an object is an expression and is by definition an lvalue.
> >
> > No, an object (in C) is a region of storage (memory), certainly not an
> > expression[0]. An lvalue _is_ an expression that designates an
> > object[1] - some kind of label that refers to the bytes which make up
> > the object. So the declaration
> >
> > int i;
> >
> > sets aside a region of storage (the object) that can be referred to by
> > the identifier 'i' (an lvalue). There may be other lvalues that refer
> > to the same object - for instance, if we declare a pointer to i:
> >
> > int *p = &i;
> >
> > we now have two ways of referring to the same object - two lvalues
> > ('*p' and 'i').
> >
> > Lvalues are often thought of as 'anything that can appear on the left
> > side of an assignment expression', which is so easy to understand that
> > it's a shame that it's wrong (think of array names, and objects with
> > const-qualified types). Since it's useful to have a name for such
> > things the C89 standard introduced the idea of a 'modifiable lvalue',
> > which does fit this simple definition.
> >
> > Jeremy.
>
> Well, your explanation agrees with my understanding,
> with Pete's.
> He said that an object *is* an lvalue, where I said that an
> object *has* an lvalue, that an object and an lvalue weren't the
> same thing.
> I was reaching for a plausible explanation for his argument.... and
> apparently missed (?)
>
> I could have quoted the standards to support my statements,
> but didn't as
> it appears they can be interpreted broadly enough to produce
> conflicting
> views.
>
> I think I'll presume that my original understanding was adequate.
>
> Thanks,
>
> Bill Tallman
>
An object is the region of memory itself,
which you can access to write and read data from.
An expression which refers to it, is an lvalue.
The value of the data in the object, is just it's value.
int i; /* (i) is an lvalue */
int *p = &i; /* (*p) is an lvalue, (&i) is an rvalue */
&i is a constant. You can't compile &i = p;
In the statement i = 5;
i=5; is a statement
i=5 is an expression
i is an lvalue
= is an assignement operator
5 is an rvalue
; is a statement terminator
i is an expression
= is an operator
5 is an expression
; is a punctuator
--
pete
William D. Tallman
> William D. Tallman wrote:
>>
>> Jeremy Yallop wrote:
>>
>> > * William D. Tallman
>> > | Thus, an object is an expression and is by definition an lvalue.
>> >
>> > No, an object (in C) is a region of storage (memory), certainly not an
>> > expression[0]. An lvalue _is_ an expression that designates an
Jeremy is saying here that an object is not an expression, and that an
lvalue is an expression. It's clear to me that he's also (necessarily?)
implying that an object is not an lvalue: it's hard to see how an entity
can both be and not be something at the same time.
>> > object[1] - some kind of label that refers to the bytes which make up
>> > the object. So the declaration
>> >
[snip]
>> Well, your explanation agrees with my understanding,
> ? but does not agree (?)
Nope.
>> with Pete's.
>> He said that an object *is* an lvalue, where I said that an
>> object *has* an lvalue, that an object and an lvalue weren't the
>> same thing.
From your post of 01-30-2002:
-----
> So every object has an lvalue, /* me */
Every object is an lvalue. /* you */
The value of either an rvalue or an lvalue,
can be assigned to an lvalue.
-----
> An object is the region of memory itself,
> which you can access to write and read data from.
Yep.
> An expression which refers to it, is an lvalue.
Yep. It refers to it but is not (identical with) it.
> The value of the data in the object, is just it's value.
Stuff assigned to (stored in) the object. On the right side of the
expression, hence rvalue in that context, but okay....
> int i; /* (i) is an lvalue */
Right.
> int *p = &i; /* (*p) is an lvalue, (&i) is an rvalue */
Yep. '*p' is a pointer to 'i', if (and only if?) it is assigned thereto.
Otherwise it's something to make a newbie nervous...lol!!!!!
> &i is a constant. You can't compile &i = p;
'&i' is the address of 'i', and as assigned to '*p' is specifically the
address of the beginning of the object labeled with the lvalue 'i' (or
maybe it is anyway..). Whatever else it is, it's not a variable...<grin>
> In the statement i = 5;
> i=5; is a statement
> i=5 is an expression
> i is an lvalue
> = is an assignement operator
> 5 is an rvalue
> ; is a statement terminator
> i is an expression
> = is an operator
> 5 is an expression
> ; is a punctuator
Okay, that's all as I understood it.
Gawd, it looks like we're picking at nits here, but this newbie has an
ominous feeling that a lack of thorough understanding here could generate
nasty "gotcha's".
Thanks,
Bill Tallman
Pai-Yi HSIAO
> Pai-Yi HSIAO wrote:
> > 3.15
> > [#1] object
> > region of data storage in the execution environment, the
> > contents of which can represent values
> >
> > 6.3.2.1 Lvalues and function designators
> > [#1] An lvalue is an expression with an object type or an
> > incomplete type other than void;46) if an lvalue does not
> > designate an object when it is evaluated, the behavior is
> > undefined.
>
> int i;
> i is an lvalue which *does* designate an object when evaluated.
> *(&i + 1), is an lvalue which *does not* designate an object when
> evaluated.
> (*(&i + 1) = 5), won't generate a compiler warning, but it's undefined.
> *(&i + 1) is an lvalue, 5 is an rvalue.
> (5 = *(&i + 1)), won't compile.
'5' is also an expression of type int and it hence an lvalue.
To evalue an lvalue which doesn't designate an object is undefined.
The standard gives the possibility to compile the statement
"5 = *(&i + 1)"
in some special machine because
"5 = *(&i + 1)" is not a contraint violation.
>
> (i=0) has a value, it is an expression. [of object type int].
It hence should be an lvalue. But there is an expection stated in
6.5.16#3 that an assignment expression is not an lvalue.
> (i=0) does not have an address, &(i=0) is meaningless, therefore
> (i=0) is an rvalue, but not a variable.
The standard doen'st say that.
In practics, the value of the expression (i=0) is stored somewhere in the
memory.
We can think about it is something like "modified lvalue".
(Although the standard has said it isn't.)
> You can wrap an expression in extra parentheses.
> (((i=0)))
> x = (i=0); assigns the value of an rvalue(i=0), to an lvalue(X)
>
> You can't wrap a statement in parentheses, x = (i=0;)
>
> Even though you can't access the address of a register variable,
> it is still "a named region of storage", which you can read
> and write data to, so registers are lvalues too.
I agree with you.
So '5' is a constant and also an lavlue (un-modifiable).
paiyi
Lawrence Kirby
<ff8ef364.02012...@posting.google.com>
sriniva...@yahoo.com "srinivas reddy" wrote:
>Recently I came across this statement:
>" the r-value of targ after executing assignment targ = source; is
>equal to the r-value of source before executing the command".
C doesn't have commands, what you have above is a statement, more
specifically an expression stastement. C also doesn't define the
term r-value. targ must be a modifiable lvalue for this to work and
what is stored in the object it designates is a value.
>Is this statement conforms to what the standard says? If not I would
>appreciate if anybody provides the reason also.
It it along the right lines as long as the assignment is valid and
targ and source have the same type. If they don't have the same type
then there may be a conversion that changes the value from source before
it is stored in targ.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
pete
>
> On Thu, 31 Jan 2002, pete wrote:
> > Pai-Yi HSIAO wrote:
> > > 3.15
> > > [#1] object
> > > region of data storage in the execution environment, the
> > > contents of which can represent values
> > >
> > > 6.3.2.1 Lvalues and function designators
> > > [#1] An lvalue is an expression with an object type or an
> > > incomplete type other than void;46) if an lvalue does not
> > > designate an object when it is evaluated, the behavior is
> > > undefined.
> So '5' is a constant and also an lavlue (un-modifiable).
5 is not an lvalue.
Constants aren't objects.
--
pete
Pai-Yi HSIAO
> Pai-Yi HSIAO wrote:
> > On Thu, 31 Jan 2002, pete wrote:
> > > Pai-Yi HSIAO wrote:
> > > > 3.15
> > > > [#1] object
> > > > region of data storage in the execution environment, the
> > > > contents of which can represent values
> > > >
> > > > 6.3.2.1 Lvalues and function designators
> > > > [#1] An lvalue is an expression with an object type or an
> > > > incomplete type other than void;46) if an lvalue does not
> > > > designate an object when it is evaluated, the behavior is
> > > > undefined.
> > I agree with you.
> > So '5' is a constant and also an lavlue (un-modifiable).
>
> 5 is not an lvalue.
Do you agree that '5' is an expression of integer type?
If yes, '5' IS an lvalue.
> Constants aren't objects.
Where will '5' be stored in an architecture?
It's stored in some region of the execution environment.
Also the contents of this region represent value.
So it IS an object.
Think of the string literal: "Hello word!"
Think of compound literal: (int[]){1,2,3}
They are all objects as well as lvalues (non-modifiable) according to C99.
paiyi
Dik T. Winter
> On Fri, 1 Feb 2002, pete wrote:
> > 5 is not an lvalue.
>
> Do you agree that '5' is an expression of integer type?
> If yes, '5' IS an lvalue.
>
> > Constants aren't objects.
>
> Where will '5' be stored in an architecture?
Perhaps as some bits in the instruction stream? But even if it is
stored explicitly somewhere in the execution environment, that does
not make 5 the object, it would make the region of memory that contains
5 the object; 5 is the contents.
> It's stored in some region of the execution environment.
> Also the contents of this region represent value.
> So it IS an object.
Nope the region is the object. 5 is not.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Pai-Yi HSIAO
> > Where will '5' be stored in an architecture?
> Perhaps as some bits in the instruction stream? But even if it is
> stored explicitly somewhere in the execution environment, that does
> not make 5 the object, it would make the region of memory that contains
> 5 the object; 5 is the contents.
>
> > It's stored in some region of the execution environment.
> > Also the contents of this region represent value.
> > So it IS an object.
>
> Nope the region is the object. 5 is not.
6.4.4 Constants
Constraints
[#2] The value of a constant shall be in the range of
representable values for its type.
Semantics
[#3] Each constant has a type, determined by its form and
value, as detailed later.
According to the standard,
constant means the "region" which stores the value.
It's why [#2] says "The value of a constant ..." instead of
"The constant".
From this point, the constant '5', which represents the region storing the
number 5, is an object as well as an lvalue.
paiyi
Dik T. Winter
> On Fri, 1 Feb 2002, Dik T. Winter wrote:
> > > Where will '5' be stored in an architecture?
> > Perhaps as some bits in the instruction stream? But even if it is
> > stored explicitly somewhere in the execution environment, that does
> > not make 5 the object, it would make the region of memory that contains
> > 5 the object; 5 is the contents.
> >
> > > It's stored in some region of the execution environment.
> > > Also the contents of this region represent value.
> > > So it IS an object.
> >
> > Nope the region is the object. 5 is not.
>
> 6.4.4 Constants
> Constraints
> [#2] The value of a constant shall be in the range of
> representable values for its type.
> Semantics
> [#3] Each constant has a type, determined by its form and
> value, as detailed later.
>
> According to the standard,
> constant means the "region" which stores the value.
Where do you find that it means the "region"?
> It's why [#2] says "The value of a constant ..." instead of
> "The constant".
Of course it talks about the value of the constant. A constant is
not a value of itself, it is only a symbolic representation of that
value. An object is some kind of label that identifies a series of
continuous bytes in memory, where the interpretation of those bytes
is either specifically defined by the standard or by the implementation.
A constant is no such beast. It can happen that an instance of '5'
is represented in binary as '100' in the instruction stream, nobody
knows, nor cares. Moreover, when multiple instances of '5' are stored
somewhere, there is nothing that says that they must be in the same
place and in the same representation.
Pai-Yi HSIAO
> > According to the standard,
> > constant means the "region" which stores the value.
> Where do you find that it means the "region"?
> > It's why [#2] says "The value of a constant ..." instead of
> > "The constant".
>
> Of course it talks about the value of the constant. A constant is
> not a value of itself, it is only a symbolic representation of that
> value. An object is some kind of label that identifies a series of
> continuous bytes in memory, where the interpretation of those bytes
> is either specifically defined by the standard or by the implementation.
> A constant is no such beast. It can happen that an instance of '5'
> is represented in binary as '100' in the instruction stream, nobody
> knows, nor cares. Moreover, when multiple instances of '5' are stored
> somewhere, there is nothing that says that they must be in the same
> place and in the same representation.
Well, you have reason to say constant is a symbol. :-)
But you can not refuse that the number '5' is an expression of integer
type.
As a consequence, '5' is an lvalue according to the standard although
it may not designate an object.
paiyi
Dik T. Winter
> type.
> As a consequence, '5' is an lvalue according to the standard although
> it may not designate an object.
Yup, you are right. In C99 it is an lvalue, even a modifiable lvalue.
In C89 it was not an lvalue. So in C99 the following statement:
5 = 3;
is valid. But we get undefined behaviour instead.
I get a deja vu from my Fortran days.
pete
>
> In article <Pine.A41.4.10.102020...@moka.ccr.jussieu.fr> Pai-Yi HSIAO <hs...@ccr.jussieu.fr> writes:
> > On Fri, 1 Feb 2002, pete wrote:
> ...
> > > 5 is not an lvalue.
> >
> > Do you agree that '5' is an expression of integer type?
> > If yes, '5' IS an lvalue.
> >
> > > Constants aren't objects.
> >
> > Where will '5' be stored in an architecture?
>
> Perhaps as some bits in the instruction stream?
Perhaps not. All that a statement like
i=5;
implies, is that there will be a value of 5, in i, when the
statement is completed.
It doesn't imply that a value of 5, is stored somewhere prior
to being loaded into i.
All that the compiler has to do, is to generate an opcode which
results in i, having a value of 5.
It's more obvious in a statement like
i=0;
which the compiler is most likely to render as some sort of
"clear register" instruction.
--
pete