Friendly-C

[via Digitalmars-d]

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".