[snip]
But there is a sentence following it:
"if an lvalue does not designate an object when it is evaluated, the
behavior is undefined."
So, while the constant 42 is of an object type, it is not an object, and
any use as an lvalue will result in undefined behaviour.[/QUOTE]
What I think you mean to say is: according to how lvalue is
defined in the standard, any evaluation of 42 (because it is
an lvalue and does not designate an object) will result in
undefined behavior.
Clearly an evaluation of an integer constant isn't supposed to
cause undefined behavior.
Back to your comments:
I do not know whether this comment is indeed true. I am not going to
read the complete standard now. But *when* an lvalue that is not an
object type is evaluated, the result is UB.
Are you confusing the two concepts? Having object type is a
static property of expressions; whether the result of an
evaluation designates an object is a run-time property of the
value of an expression's evaluation. Almost all expressions
that are lvalues have object type; the exceptions are things
like array names of unknown length and a few other things that
people hardly ever write in actual programs.
Which means that an evaluatable lvalue is precisely
what you describe. [snip]
First let me distinguish two terms. An lvalue(S) is an
lvalue as it is defined in the standard. An lvalue(U) is
an lvalue as understood by most CLC regulars and by all
the implementations I'm familiar with.
Using that terminology, what you're saying is that I'm
describing an evaluatable lvalue(S).
My intention was to describe an lvalue(U); whether that
corresponds to an evaluatable lvalue(S) depends on what's
meant by "evaluatable". There is nothing in my description of
lvalue(U) that says the address will actually designate an
object; eg, '* (char*) 0' is an lvalue(U), but it does not
designate an object.
Not counting that minor point though I think your point is
correct: an lvalue(U) corresponds to an lvalue(S) for which
evaluation is plausible.
Why do people (including myself) think this? Various statements
in sections 6.5.x that certain kinds of expressions -- but not
all expressions with object type -- are lvalues;
Pray provide a reference. I have looked through the draft and did
not find any such statements. [...also for footnotes...]
The index for "lvalue" shows 6.5.1, 6.5.2.4, 6.5.3.1, and
6.5.16. The footnotes include numbers 95, 92 and 94; I
believe these numbers correspond to numbers 76, 83 and 85 in
N869. I'm pretty sure this list isn't complete; I haven't
attempted to do any kind of exhaustive search.
Depends on the types of a and b.
Actually I think the expression '&(a+b)' is nonsense no matter
what the types of a and b are.
But when they are (say) integer
variables, the expression is indeed an lvalue.
The expression '(a+b)' is an lvalue(S). It is not an
lvalue(U).
But the address
operator requires evaluation, and there you are. UB, because there
is not an object.
Consider this expression:
sizeof &(a+b)
Assuming no variable length arrays, there is no evaluation of
the address operator; however, the expression is still
illegal:
$ cat lvalue.c
void
foo(){
int a, b;
sizeof &(a+b);
}
$ gcc -ansi -pedantic lvalue.c
lvalue.c: In function `foo':
lvalue.c:4: invalid lvalue in unary `&'
$ gcc -std=c99 -pedantic lvalue.c
lvalue.c: In function `foo':
lvalue.c:4: invalid lvalue in unary `&'