On 03/07/2012 02:09 PM, Jonathan M Davis wrote:
On Wednesday, March 07, 2012 07:55:35 H. S. Teoh wrote:
It's not that the null pointer itself corrupts memory. It's that the
null pointer is a sign that something may have corrupted memory *before*
you got to that point.
The point is, it's impossible to tell whether the null pointer was
merely the result of forgetting to initialize something, or it's a
symptom of a far more sinister problem. The source of the problem could
potentially be very far away, in unrelated code, and only when you tried
to access the pointer, you discover that something is wrong.
At that point, it may very well be the case that the null pointer isn't
just a benign uninitialized pointer, but the result of a memory
corruption, perhaps an exploit in the process of taking over your
application, or some internal consistency error that is in the process
of destroying user data. Trying to continue is a bad idea, since you'd
be letting the exploit take over, or allowing user data to get even more
corrupted than it already is.
Also, while D does much more to protect you from stuff like memory corruption
than C/C++ does, it's still a systems language. Stuff like that can definitely
happen. If you're writing primarily in SafeD, then it's very much minimized,
but it's not necessarily eliminated. All it takes is a bug in @system code
which could corrupt memory, and voila, you have corrupted memory, and an @safe
function could get a segfault even though it's correct code. It's likely to be
a very rare occurrence, but it's possible. A since when you get a segfault,
you can't know what caused it, you have to assume that it could have been
caused by one of the nastier possibilites rather than a relatively benign one.
And since ultimately, your program should be checking for null before
derefencing a variable in any case where it could be null, segfaulting due to
dereferencing a null pointer is a program bug which should be caught in
testing - like assertions in general are - rather than having the program
attempt to recover from it. And if you do _that_, the odds of a segfault being
due to something very nasty just go up, making it that much more of a bad idea
to try and recover from one.
- Jonathan M Davis
I can see where you're coming from now.
As I mentioned in another post, my lack of consideration for this
indicator of memory corruption is probably a reflection of my bias
towards VM'd languages.
I still don't buy the whole "it's a program bug that should be caught in
testing". I mean... true, but sometimes it isn't. Especially since
testing and assertions can never be %100 thorough. What then? Sorry,
enjoy your suffering?
At that point I would like to have a better way to do sentinel values.
I'd at least like to get an exception of some kind if I try to access a
value that /shouldn't/ be there (as opposed to something that /should/
be there but /isn't/).
Combine that with sandboxing and I might just be satisfied for the time
being.
See my reply to Steve for more details. It's the one that starts like this:
Example?
Here, if you want, I'll start with a typical case. Please make it right.
class UnreliableResource
{
this(string sourceFile) {...}
this(uint userId) {...}
void doTheThing() {...}
}
