On 7/27/17 3:50 PM, Moritz Maxeiner wrote:
On Thursday, 27 July 2017 at 18:46:16 UTC, Jonathan M Davis wrote:
On Thursday, July 27, 2017 11:03:02 Steven Schveighoffer via
Digitalmars-d wrote:
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.
I see no problem whatsoever requiring that the platform segfaults when
you dereference null. Anything even vaguely modern will do that.
Adding extra null checks is therefore redundant and complicates the
compiler for no gain whatsoever.
Except that when someone gets (root) access to any modern Linux servers
running D services he now has an easy way to create a denial of service
attack the owner of the server won't easily be able to find the cause
of, because pretty much everything *looks* right, except that somehow
the D services hang.
Well, let's not forget that the services should not be dereferencing
null. It's still a bug in the code.
It just may result in something other than a process exit.
I bet if you lowered that limit, you would cause all sorts of trouble,
not just in D safe code. Imagine, any function that returns null
specifically to mean an error, now may return it casually as the address
of a valid item! You are going to screw up all checks for null!
-Steve
