dereferencing null

[Chad J]

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() {...}
> }