Inside the thread for adding @safe/@trusted attributes to OS functions,
it has come to light that @safe has conflicting rules.
For the definition of safe, it says:
"Safe functions are functions that are statically checked to exhibit no
possibility of undefined behavior."
In the definition of @trusted, it says:
"Trusted functions are guaranteed by the programmer to not exhibit any
undefined behavior if called by a safe function."
Yet, safe functions allow dereferencing of null pointers. Example:
void foo() @safe
{
int *x;
*x = 5;
}
There are various places on the forum where Walter argues that null
pointer dereferencing should cause a segmentation fault (or crash) and
is checked by the hardware/OS. Therefore, checking for null pointers
before any dereferencing would be a waste of cycles.
However, there do exist places where dereferencing null may NOT cause a
segmentation fault. For example, see this post by Moritz Maxeiner:
https://forum.dlang.org/post/udkdqogtrvanhbotd...@forum.dlang.org
In such cases, the compiled program can have no knowledge that the zero
page is mapped somehow. There is no way to prevent it, or guarantee it
during compilation.
It's also worth noting that C/C++ identifies null dereferencing as
undefined behavior. So if we are being completely pedantic, we could say
that no C/C++ code could be marked safe if there is a possibility that a
null pointer would be dereferenced.
The way I see it, we have 2 options. First, we can disallow null pointer
dereferencing in @safe code. This would be hugely disruptive. We may not
have to instrument all @safe code with null checks, we could do it with
flow analysis, and assuming that all pointers passed into a @safe
function are not null. But it would likely disallow a lot of existing
@safe code.
The other option is to explicitly state what happens in such cases. I
would opt for this second option, as the likelihood of these situations
is very low.
If we were to update the spec to take this into account, how would it look?
A possibility:
"@safe D does not support platforms or processes where dereferencing a
null pointer does not crash the program. In such situations,
dereferencing null is not defined, and @safe code will not prevent this
from happening."
In terms of not marking C/C++ code safe, I am not convinced we need to
go that far, but it's not as horrible a prospect as having to unmark D
@safe code that might dereference null.
Thoughts?
-Steve
