Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...
a
*a
a[1]
*(a + 1)
....
What else?
What grammar/regexp describes all valid lvalues?
14  4347  no****@gmail.com wrote:
Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...
a
*a
a[1]
*(a + 1)
...
What else?
All of these might or might not be lvalues, depending
on what `a' is.
What grammar/regexp describes all valid lvalues?
It would be straightforward, although tedious, to write
a grammar that generates all lvalue expressions, but it would
also accept some expressions that are not lvalues. The
property of being an lvalue is semantic, not grammatical.
--
Eric Sosman es*****@acm-dot-org.invalid
On Mar 6, 7:54 am, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>
[...]
a
*a
a[1]
*(a + 1)
...
What else?
All of these might or might not be lvalues, depending
on what `a' is.
[...]
Why do you say *a, a[1] and *(a + 1) may not be lvalues? For as much
as know, the unary * operator and the [] operator always require an
expression that represents a valid object's address, and they always
return lvalues.
rg
Rg wrote On 03/06/07 13:11,:
On Mar 6, 7:54 am, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>>[...]
>>>a
*a
a[1]
*(a + 1)
...
What else?
All of these might or might not be lvalues, depending
on what `a' is.
[...]
Why do you say *a, a[1] and *(a + 1) may not be lvalues? For as much
as know, the unary * operator and the [] operator always require an
expression that represents a valid object's address, and they always
return lvalues.
int a[5][10];
a[1] = ...?
-- Er*********@sun.com
Eric Sosman wrote On 03/06/07 13:41,:
Rg wrote On 03/06/07 13:11,:
>>On Mar 6, 7:54 am, Eric Sosman <esos...@acm-dot-org.invalidwrote:
>>>[...]
a
*a
a[1]
*(a + 1)
...
What else?
All of these might or might not be lvalues, depending
on what `a' is.
[...]
Why do you say *a, a[1] and *(a + 1) may not be lvalues? For as much
as know, the unary * operator and the [] operator always require an
expression that represents a valid object's address, and they always
return lvalues.
int a[5][10];
a[1] = ...?
On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:
int a(void);
*a = ...?
-- Er*********@sun.com
On Mar 7, 7:59 am, Eric Sosman <Eric.Sos...@sun.comwrote:
Eric Sosman wrote On 03/06/07 13:41,:
int a[5][10];
a[1] = ...?
On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:
int a(void);
*a = ...?
In C99, a[1] is not an lvalue if it does not designate valid storage,
eg.
char *a = NULL;
a[1];
On Mar 6, 11:06 am, nob...@gmail.com wrote:
Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...
a
*a
a[1]
*(a + 1)
...
What else?
What grammar/regexp describes all valid lvalues?
Purely syntactically though, can you write a grammar that recognizes
valid lvalues.
Old Wolf wrote On 03/06/07 16:46,:
On Mar 7, 7:59 am, Eric Sosman <Eric.Sos...@sun.comwrote:
>>Eric Sosman wrote On 03/06/07 13:41,:
>> int a[5][10];
a[1] = ...?
On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:
int a(void);
*a = ...?
In C99, a[1] is not an lvalue if it does not designate valid storage,
eg.
char *a = NULL;
a[1];
Perhaps the verbiage changed; my C99 is not close at
hand for checking. In TC2 (May 2005), a[1] is an lvalue
"An /lvalue/ is an expression with an object type
or an incomplete type other than void;"
The fact that `a' is NULL doesn't destroy the lvalue-ness,
but causes other problems instead:
"if an lvalue does not designate an object when it
is evaluated, the behavior is undefined."
(Both quotes from 9899:TC2, section 6.3.2.1 paragraph 1.)
To get back to the O.P.'s question, though: I don't
believe it's possible to distinguish lvalues from non-
lvalues on purely syntactic grounds (the grammar in the
Standard does not do so), and it's certainly beyond the
reach of a regular expression.
-- Er*********@sun.com
"Old Wolf" <ol*****@inspire.net.nzwrites:
On Mar 7, 7:59 am, Eric Sosman <Eric.Sos...@sun.comwrote:
>Eric Sosman wrote On 03/06/07 13:41,:
int a[5][10];
a[1] = ...?
On second thought, I retract this example: a[1] is
in fact an lvalue, but not a modifiable lvalue. Try
this one instead:
int a(void);
*a = ...?
In C99, a[1] is not an lvalue if it does not designate valid storage,
eg.
char *a = NULL;
a[1];
The C90 definition of "lvalue" was badly messed up. The C99
definition is arguably worse. Neither one completely captures the
intended meaning.
C90 6.2.2.1 says:
An _lvalue_ is an expression (with an object type or an incomplete
type other than void) that designates an object.
That's close to the actual intent, but there's a problem: taken
literally, it implies that certain expressions may or may not be
lvalues depending on their current value. For example:
int x;
int *ptr = &x;
/* *ptr is an lvalue, since it designates the object x. */
ptr = NULL;
/* *ptr no longer designates an object. */
But where the standard requires an expression to be an lvalue, it's a
constraint that must be satisified at compilation time.
C99 tried and failed to fix the definition. C99 6.3.2.1p1:
An _lvalue_ is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an object
when it is evaluated, the behavior is undefined.
That avoids the problem with the C90 definition, but it fails to
express the idea that designating an object is what lvalue-ness is all
about. A literal reading of the C99 definition says that 42 is an
lvalue (it's an expression of type int, and int is an object type),
and that any attempt to evaluate the expression 42 invokes undefined
behavior.
The *intent* is that an lvalue is an expression that *potentially*
designates an object, i.e., that can do so for certain values of the
expression and its subexpressions. *ptr is an lvalue whether
*currently* designates an object or not; if it doesn't currently
designate an object, attempting to use it *as an lvalue* invokes
undefined behavior.
(The older, pre-ANSI meaning of the term "lvalue" is not the
expression itself, but the result of evaluating an expression to
determine what object it designates, as oppposed to an "rvalue" which
is what ISO C simply calls the value of the expression.)
--
Keith Thompson (The_Other_Keith) ks***@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister" no****@gmail.com wrote:
On Mar 6, 11:06 am, nob...@gmail.com wrote:
>Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...
a
*a
a[1]
*(a + 1)
...
What else?
What grammar/regexp describes all valid lvalues?
Purely syntactically though, can you write a grammar that recognizes
valid lvalues.
(It seems you haven't been paying attention ... Ah, well.)
Here is a regular expression that matches all lvalues:
.*
Have fun!
--
Eric Sosman es*****@acm-dot-org.invalid
On Mar 7, 2:43 am, Eric Sosman <esos...@acm-dot-org.invalidwrote:
nob...@gmail.com wrote:
On Mar 6, 11:06 am, nob...@gmail.com wrote:
Yes I know what lvalue means, but what I want to ask you guys about is
what are all valid lvalues ...
a
*a
a[1]
*(a + 1)
...
What else?
What grammar/regexp describes all valid lvalues?
Purely syntactically though, can you write a grammar that recognizes
valid lvalues.
(It seems you haven't been paying attention ... Ah, well.)
Here is a regular expression that matches all lvalues:
.*
Have fun!
--
Eric Sosman
esos...@acm-dot-org.invalid
Cute ... Ill see how far I get with .*
All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.
The original motivation is now gone, and this is now purely an
academic question. no****@gmail.com wrote On 03/07/07 11:30,:
[...]
All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.
The original motivation is now gone, and this is now purely an
academic question.
nobrow, it's been explained -- several times -- that
"lvalue-ness" is not a syntactic property. The definition
of lvalue has been quoted, from multiple versions of the
C Standard (the text has changed over time). The only
"syntactical" piece is that an lvalue must be an expression,
so we can conclude (for instance) that ;-) cannot be part
of an lvalue because it cannot be part of an expression.
We can also conclude (see Keith Thompson's post) that 42
is not an lvalue even though it is a syntactically valid
expression. But there remains a large class of expressions
that might or might not be lvalues, depending on the context.
It's not a syntactic question, certainly not for a context-
free grammar.
Very few languages are fully described by their syntax.
-- Er*********@sun.com
Eric Sosman <Er*********@sun.comwrites:
no****@gmail.com wrote On 03/07/07 11:30,:
>[...]
All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.
The original motivation is now gone, and this is now purely an
academic question.
nobrow, it's been explained -- several times -- that
"lvalue-ness" is not a syntactic property. The definition
of lvalue has been quoted, from multiple versions of the
C Standard (the text has changed over time). The only
"syntactical" piece is that an lvalue must be an expression,
so we can conclude (for instance) that ;-) cannot be part
of an lvalue because it cannot be part of an expression.
We can also conclude (see Keith Thompson's post) that 42
is not an lvalue even though it is a syntactically valid
expression. But there remains a large class of expressions
that might or might not be lvalues, depending on the context.
It's not a syntactic question, certainly not for a context-
free grammar.
Very few languages are fully described by their syntax.
True, but there's a reasonable question buried in there. Is there a
subset of exressions, defined syntactically, such that any member of
that subset *might* be an lvalue, and any expression not in that
subset *cannot* be an lvalue? Obviously the set of all expressions
meets that requirement, but what is the *minimal* subset, defined
syntactically, that includes all possible lvalues?
You could probably do it by considering the top-level operator of the
expression. For example, if the top-level operator is unary "sizeof",
unary "+", unary "-", multiplication, division, a bitwise or shift
operator, etc., then the expression cannot be an lvalue; if the
top-level operator is "[]", "->", etc., then it may be an lvalue. You
also have to allow for parentheses, and remember than x+y or x-y can
be an lvalue if x or y is a pointer.
--
Keith Thompson (The_Other_Keith) ks***@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson wrote:
Eric Sosman <Er*********@sun.comwrites:
>no****@gmail.com wrote On 03/07/07 11:30,:
>>[...]
All I wanted to know was the form lvalues can take. For example, when
examining code statically I know that an identifier may be an lvalue.
I know that anything that is being dereferenced could potentially be
an lvalue ... I just wanted to know if there are other pieces of
syntax that can yield lvalues.
The original motivation is now gone, and this is now purely an
academic question.
nobrow, it's been explained -- several times -- that
"lvalue-ness" is not a syntactic property. The definition
of lvalue has been quoted, from multiple versions of the
C Standard (the text has changed over time). The only
"syntactical" piece is that an lvalue must be an expression,
so we can conclude (for instance) that ;-) cannot be part
of an lvalue because it cannot be part of an expression.
We can also conclude (see Keith Thompson's post) that 42
is not an lvalue even though it is a syntactically valid
expression. But there remains a large class of expressions
that might or might not be lvalues, depending on the context.
It's not a syntactic question, certainly not for a context-
free grammar.
Very few languages are fully described by their syntax.
True, but there's a reasonable question buried in there. Is there a
subset of exressions, defined syntactically, such that any member of
that subset *might* be an lvalue, and any expression not in that
subset *cannot* be an lvalue? Obviously the set of all expressions
meets that requirement, but what is the *minimal* subset, defined
syntactically, that includes all possible lvalues?
You could probably do it by considering the top-level operator of the
expression. For example, if the top-level operator is unary "sizeof",
unary "+", unary "-", multiplication, division, a bitwise or shift
operator, etc., then the expression cannot be an lvalue; if the
top-level operator is "[]", "->", etc., then it may be an lvalue. You
also have to allow for parentheses, and remember than x+y or x-y can
be an lvalue if x or y is a pointer.
Well no. x+y is always an rvalue. *(x+y) has a chance of being an lvalue.
With all respect to you and Eric and all the rest, I contend we make too
much of the 'complexity' of what an lvalue might be. I first encountered
the term in K&R1 circa 1978. That definition was clear to me 20 years
ago when I read it and satisfies me today. To wit: p183 A.5 "Objects and
lvalues"
"An object is a manipulatable region of storage; an lvalue is an
expression referring to an object."
It worked for me then and it does now. KISS.
Also an rvalue is any expression not an lvalue. :-)
In my own view, even though an expression might refer to an object, it
becomes an lvalue only on the left of an assignment operator.
Consider:
int a, b, c; /* a, b and c are (refer to) objects */
a = 5; /* a is an lvalue */
b = a + 4; /* b is an lvalue, a is an rvalue and a + 4 is 9 */
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Joe Wright <jo********@comcast.netwrites:
Keith Thompson wrote:
[snip]
>You could probably do it by considering the top-level operator of the
expression. For example, if the top-level operator is unary "sizeof",
unary "+", unary "-", multiplication, division, a bitwise or shift
operator, etc., then the expression cannot be an lvalue; if the
top-level operator is "[]", "->", etc., then it may be an lvalue. You
also have to allow for parentheses, and remember than x+y or x-y can
be an lvalue if x or y is a pointer.
Well no. x+y is always an rvalue. *(x+y) has a chance of being an lvalue.
D'oh, you're right.
In fact, *(x+y) is definitely an lvalue (if neither x nor y is a
pointer, then it's illegal).
With all respect to you and Eric and all the rest, I contend we make
too much of the 'complexity' of what an lvalue might be. I first
encountered the term in K&R1 circa 1978. That definition was clear to
me 20 years ago when I read it and satisfies me today. To wit: p183
A.5 "Objects and lvalues"
"An object is a manipulatable region of storage; an lvalue is an
expression referring to an object."
It worked for me then and it does now. KISS.
Agreed -- with the small proviso that an expression may be an lvalue
even if it doesn't *currently* refer to an object (but if it doesn't,
and it's used in a context requiring an lvalue, then the behavior is
undefined). For example, *ptr is an lvalue even if ptr == NULL.
Also an rvalue is any expression not an lvalue. :-)
Um, not really. The standard doesn't use the term "rvalue" except in
passing in a footnote; the standard instead refers to the "value of an
expression", which is valid whether the expression happens to be an
lvalue or not. But that usage of "rvalue" is consistent with the
older meaning of "lvalue" (which someone, I don't remember who,
explained here recently). Namely, an lvalue and an rvalue are both
the result of evaluating an expression, but in different ways. An
rvalue is the result of evaluating an expression to determine an
ordinary value, such as 2+2 yielding 4. An lvalue, in this older
meaning, is the result of evaluating an expression to determine what
location it designates, such as *ptr yielding the memory location to
which ptr points (without regard to what may be currently stored in
that location). Subexpressions are evaluated for their rvalues or
their lvalues depending on the context in which they appear. If an
expression being evaluated for its lvalue doesn't currently designate
an object, the behavior is undefined.
The C standard dropped the term "rvalue" and changed the meaning of
"lvalue" so it refers to the expression itself, not to the result of
evaluating it in a particular way. In my opinion, the older usage was
more elegant; it may be a little harder to wrap you head around the
idea of evaluating something in two different ways, but it's a good
concept to have in your mental repertoire.
In my own view, even though an expression might refer to an object, it
becomes an lvalue only on the left of an assignment operator.
Consider:
int a, b, c; /* a, b and c are (refer to) objects */
a = 5; /* a is an lvalue */
b = a + 4; /* b is an lvalue, a is an rvalue and a + 4 is 9 */
That's a pretty good model too. It's a pity the standard isn't that
clear.
--
Keith Thompson (The_Other_Keith) ks***@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister" This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Hongzheng Wang |
last post by:
In K&R, they said:
An object is a named region of storage; an lvalue is an expression
refer to an object.
How about these concept in C++?
`The C++ Programming Language' has a similar...
|
by: Steven T. Hatton |
last post by:
This is from the draft of the previous version of the Standard:
http://www.kuzbass.ru:8086/docs/isocpp/expr.html
2- A literal is a primary expression. Its type depends on its form...
|
by: Michael Baehr |
last post by:
I recently upgraded my Arch Linux system to GCC 3.4, and found out that a
previously accepted behavior (cast-as-lvalue) is now marked as deprecated,
and will cease to function in GCC 3.5. This has...
|
by: Romeo Colacitti |
last post by:
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...
|
by: junky_fellow |
last post by:
Consider the following piece of code:
(char *)0x100; /* I know that converting an integer to pointer
type is implementation defined. But forget
this for a moment */
My question is,
Why the...
| | |
by: Kavya |
last post by:
Can someone give and explain in simple terms a definition of lvalue?
Also what are these modifiable and non-modifiable lvalues?
I always thought that, if we can assign to anything then that...
|
by: the_init |
last post by:
Hi friends,
I read about Lvalue in previous posting and Googled it but I'm not
understood it completely.
There is a small doubt.
int a;
a=20; // here a is Lvalue
But
|
by: Yarco |
last post by:
I've alway thought lvalue means Left Value and rvalue means Right
Value before i've read someone's article.
It is said "lvalue = location value" and "rvalue = read value".
Which one is right, then?
|
by: Pietro Cerutti |
last post by:
Hi group,
assume the following declarations:
char *func_1(void);
void func_2(char **);
I am allowed to do:
char *c = func_1();
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
