Re: Ambiguity in semantics of assignments?
From: Mark F. Haigh (mfhaigh_at_sbcglobal.net)
Date: 10/08/04
- Next message: pete: "Re: Newbie-Question: Function-Parameters"
- Previous message: pete: "Re: Off Topic: Why is stdprn not defined under Windows?"
- In reply to: Paul Steckler: "Ambiguity in semantics of assignments?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 7 Oct 2004 17:23:55 -0700
steck@ccs.neu.edu (Paul Steckler) wrote in message news:<9bc41fd7.0410061304.dd833f7@posting.google.com>...
> Here's some code that's giving me differing results, depending
> on the compiler.
<snip>
> A = foo.A += A; /* crucial statement */
>
<snip>
> The result given by gcc is what I expected. Is there any
> ambiguity in the semantics of the crucial statement here?
>
No, there's not. 6.5.16:
3 An assignment operator stores a value in the object designated
by the left operand. An assignment expression has the value of
the left operand after the assignment, but is not an lvalue.
The type of an assignment expression is the type of the left
operand unless the left operand has qualified type, in which
case it is the unqualified version of the type of the left
operand. The side effect of updating the stored value of the
left operand shall occur between the previous and the next
sequence point.
The value of the += in 'foo.A += A' is well defined, even though the
state of the foo.A object itself is indeterminite until the next
sequence point. It is the value of the +=, not the value of foo.A,
that should be stored in A. This may be where the compiler gets it
wrong.
As you noted in another post, this is a compiler bug, and from the
looks of it, a relatively severe one. Hmmm.
Mark F. Haigh
mfhaigh@sbcglobal.net
- Next message: pete: "Re: Newbie-Question: Function-Parameters"
- Previous message: pete: "Re: Off Topic: Why is stdprn not defined under Windows?"
- In reply to: Paul Steckler: "Ambiguity in semantics of assignments?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|