Netocrat said:
Perhaps that was an inflammatory thing to say.
[snip]
No, it wasn't, really. Indeed lvalue-ness of expressions could depend
on their evaluation (ie. only expressions with valid behaviour are
lvalues). But then being an lvalue would not be diagnosable at compile-
time. Fine. Expressions like `7 = 11' would yield only UB during
run time. Good.
It is not so (fortunately), lvalue property is referred to in Constrains
in many places, therefore it must be known before evaluation of
an expression. The Standard ought to specify it for every expression,
irrespective of its validity.
Dereferencing an object pointer (other than void*) is always an
lvalue (if it isn't then it ought to be). If it appropriate type
(non-const, non-array, etc.), it's a modifiable lvalue. (It is
conceivable to imagine a scenario where it wasn't an lvalue.)
Some expressions are non-lvalues, eg. cast expressions; gcc used
to have an extension where some cast expressions were lvalues.
The expression `*(int*)0' is a modifiable lvalue. It can be diagnosed,
and a compiler could refuse to compile it if it could prove it would
be evaluated. I believe it couldn't reject this code:
if (0) *(int*)0 = 7;
Why back away from your original strong statement that "being an lvalue is
a compile-time property"?
I was just acknowledging the fact that the Standard didn't define it.
I think it ought to.
From the quote in my other post, the standard
says: "if an lvalue does not designate an object when it is evaluated, the
behavior is undefined." This exactly describes the case we're discussing.
It is both an lvalue and invokes undefined behaviour on being assigned to.
It's true, but `*(int*)0' should also be an lvalue (apart from invoking UB);
the Standard (probably) does not say so (at least not explicitly).
struct s { int a[1]; };
struct s f(void);
f().a[0] = 7; //UB
The expression on the left is clearly a modifiable lvalue.
This is a minor variation on an example from a previous thread in c.l.c:
struct s {...} s1, s2;
(s1 = s2).a[0] = 7; //UB
I remember reading that thread - "Undefined behaviour when modifying the
result of an assignment operator".
Not so clearly according to gcc. I get: "ISO C90 forbids subscripting
non-lvalue array".
gcc is lying. The expression "f().a[0]" is perfectly valid.
It's perfectly valid as a non-modifiable lvalue; but we both agree that
assigning to it as a modifiable lvalue invokes undefined behaviour.
Try it with on-line como - there's not a single warnings.
Cut'n'paste version:
int main()
{
struct s { int a[1]; };
struct s f(void);
f().a[0] = 7; /*UB*/
}
[snip]
int a[1];
a[0];
`a' is not a modifiable lvalue, `a[0]' is (cf. Rationale).
Agreed, but I was talking about f(), not f().a. In the case of f(), it
does have to be. If the struct returned by f() is not a modifiable
lvalue, then neither are the elements of its member array.
It doesn't matter, really. `a' is not an lvalue, but `a[0]' is.
Similarly, `f().a' is not an lvalue; `f().a[0]' is the same as
`*(f().a + 0)', dereferencing a pointer is always an lvalue (in
this case it is even well defined by the Std, because `f().a'
presumably points to some valid temporary storage). Since its type
is `int', it's a modifiable lvalue.
So I'll reinterpret my statement: assuming that the storage temporarily
exists (which conceptually it does), and pretending that we are not
prohibited from assigning to it by 6.5.2.2#5, the assignment has no effect
anyway (it's a no-op) since we cannot at any later point retrieve the
assigned value (the temporary storage disappears immediately after the
assignment statement).
Imagine this:
struct s { int a[1]; };
struct s sfunc(void)
{
static const struct s s; //const is optional, but more illustrative here
return s;
}
int main()
{
sfunc().a[0] = 7; //UB
}
The compiler might make an optimization an reuse the storage of `s' for
the return value (ie. not create a temporary storage). I'm sure you
can see what a disaster it would make.
Actually, if "UB" line wasn't an UB, the compiler could not make such
an optimization. I think it's for this reason (so that it can) that
"UB" is UB. It's the same story with the result of "=" operator.
[...]
int f(void);
f() = 7; /* UB for the same reason but more obviously so */
Erm... strictly speaking, no, because it won't compile. And if it
would then behaviour of "=" would raise UB, since LHS is not an lvalue.
