On 7/26/17 7:55 AM, Timon Gehr wrote:
On 26.07.2017 13:22, Steven Schveighoffer wrote:
On 7/26/17 6:01 AM, Timon Gehr wrote:
On 26.07.2017 03:09, Steven Schveighoffer wrote:
...
In other words, I think we can assume for any C functions that are
passed pointers that dereference those pointers, passing null is
safely going to segfault.
I'm not going to assume that.
Tell you what, when you find a D platform that this doesn't happen, >
we can fix it with a version statement ;)
The burden of proof is on you, not me. You are advocating the C approach
to memory safety.
They leave NULL dereferencing undefined because in some quirky old
useless no-longer-existing hardware, it doesn't segfault.
Note that this is more implementation defined than undefined (in fact, I
couldn't find it listed in the UB section at all in the C11 spec).
Look at Walter's response. I think D can simply only work with C
implementations on platforms where null dereferencing segfaults and
ignore the rest.
Walter, can we update the @safe spec to say that reading/writing data
from the null page in C is required to generate a program crash for
@safe to be valid? This can be an exception to the UB rule.
I just don't see the point of adding extra checks for null when the
hardware already does it.
-Steve
