On Friday, 29 August 2014 at 19:37:28 UTC, deadalnix wrote:
> NULL or any address, as you can change memory protection on a per
> page basis, and have different protection for read write and
> execution.

If your semantics require page faults to trap then you should declare the storage volatile.

You cannot claim that the semantics of your program presumes that the program is incorrect?

Now, the programming language might require compiled programs to probe measures of incorrectness at some specific point in time: before compilation, before output is written to disk or after completion (with a rollback), but that is the semantics of a given language, not the semantics of the program. Thus it bears little relevance to a discussion of whether it is sound to assume unspeficied values and avoid stores.

> Even better, the fault do not have to result in an exception or
> other form of termination. in fact, it is demonstrated that the
> fault mechanism on x86 is Turing complete.

I don't see what TMs have to do with it. The language compiler controls generated code.

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.

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.

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

On Friday, 29 August 2014 at 21:03:59 UTC, Ola Fosheim Grøstad
wrote:
> On Friday, 29 August 2014 at 19:37:28 UTC, deadalnix wrote:
>> NULL or any address, as you can change memory protection on a per
>> page basis, and have different protection for read write and
>> execution.
>
> If your semantics require page faults to trap then you should declare the storage volatile.
>

Or what ? Or it is undefined behavior ?

On Friday, 29 August 2014 at 21:35:11 UTC, Marc Schütz wrote:
> "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).

"either" => it can produce an unspecified value without trapping.

(But Friendly-C is not a coherent spec, it is a blog post…)

> But still, taken together with point 4, it is debatable whether trapping counts as "redundant or otherwise useless".

You have to look at the intended semantics of the program and how to make it correct. If loads and stores are meant to have side effects then it should be declared volatile, that is what "volatile" is for. (or use asm or an intrinsic with volatile semantics).

On Saturday, 30 August 2014 at 00:50:23 UTC, deadalnix wrote:
> On Friday, 29 August 2014 at 21:03:59 UTC, Ola Fosheim Grøstad
>> If your semantics require page faults to trap then you should declare the storage volatile.
>>
>
> Or what ? Or it is undefined behavior ?

Or else you cannot rely on them to fire.

Traps are for specifying "extensions" to the hardware logic defaults (e.g. creating an emulator). If traps don't fire it basically means the extensions aren't needed for a correct program?