On 2014-01-06 21:09:44 +0000, Walter Bright <newshou...@digitalmars.com> said:
On 1/6/2014 1:03 PM, Walter Bright wrote:
On 1/6/2014 11:21 AM, deadalnix wrote:
Or, we can decide that trapping in not guaranteed, and then dereferencing null
is undefined behavior,
which is much worse that a compile time failure.
Realistically, this is a non-problem.
Or better, if you want to issue a pull request for the documentation
that says unless it is a dead load, a null reference will cause a
program-ending fault of one sort or another, I'll back it.
That's pretty much the same as undefined behaviour because "dead load"
is not defined. What is a dead load actually depends on how much
inlining is done and how the optimizer works, and that's hard to define
as part of the language.
For instance, you could dereference a value and pass it to a function
(as in "foo(*x)"). If that function gets inlined, and if what that
function does is it multiplies the passed integer by zero, then the
optimizer might rewrite the program to never load the value, the null
dereference has simply disappeared.
I think the best way to describe what happens is this: The only
guaranty made when dereferencing a null pointer is that the program
will stop instead of using a garbage value. An optimizing compiler
might find ways to avoid or delay using dereferenced values which will
allow the program to continue running beyond the null dereference. In
general one shouldn't count on dereferencing a null pointer to stop a
program at the right place or at all.
I think this is a good explanation of what happens, but it obviously
leaves undefined the *if and when* it'll stop the program because this
highly depends on inlining and what the optimizer does.
--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca
