On Friday, 29 August 2014 at 21:09:09 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 29 August 2014 at 20:54:10 UTC, Marc Schütz wrote:
If it was indeed unexpected then you're right, but how do you
know it wasn't intentional?
Because then it should have been declared volatile?
If accessing an invalid pointer isn't unspecified behaviour
(which this discussion is about), then why shouldn't someone
rely on it?
Not sure what you mean by unspecified behaviour for pointers.
The discussion was about unspecified values for value types.
I didn't really get that from reading the exchange between you
and deadalnix, sorry. You were talking about loads and stores, so
I assumed pointers are involved.
The statement "a = a;" does nothing unless a is volatile. If a
is read-only then the statement is incorrect. Removing an
incorrect do-nothing statement is quite acceptable.
This is what I was thinking about in my first reply to you, from
the article in the OP:
"4. Reading from an invalid pointer either traps or produces an
unspecified value. In particular, all but the most arcane
hardware platforms can produce a trap when dereferencing a null
pointer, and the compiler should preserve this behavior."
As I read it, they suggest that an invalid pointer access should
trap (but permit yielding an unspecified value).
On the other hand, point 13. directly covers the "a = a;" case:
"The compiler retains the ability to optimize away pointer
dereferences that it can prove are redundant or otherwise
useless."
But still, taken together with point 4, it is debatable whether
trapping counts as "redundant or otherwise useless".
