dereferencing null

Steven Schveighoffer schveiguy at yahoo.com
Wed Mar 7 07:21:00 PST 2012


On Wed, 07 Mar 2012 10:10:32 -0500, Chad J  
<chadjoan at __spam.is.bad__gmail.com> wrote:

> On Wednesday, 7 March 2012 at 14:23:18 UTC, Chad J wrote:
>> On 03/07/2012 07:57 AM, Steven Schveighoffer wrote:
>>> On Mon, 05 Mar 2012 23:58:48 -0500, Chad J
>>> <chadjoan at __spam.is.bad__gmail.com> wrote:
>>>
>>>>
>>>> Why is it fatal?
>>>
>>> A segmentation fault indicates that a program tried to access memory
>>> that is not available. Since the 0 page is never allocated, any null
>>> pointer dereferencing results in a seg fault.
>>>
>>> However, there are several causes of seg faults:
>>>
>>> 1. You forgot to initialize a variable.
>>> 2. Your memory has been corrupted, and some corrupted pointer now  
>>> points
>>> into no-mem land.
>>> 3. You are accessing memory that has been deallocated.
>>>
>>> Only 1 is benign. 2 and 3 are fatal. Since you cannot know which of
>>> these three happened, the only valid choice is to terminate.
>>>
>>> I think the correct option is to print a stack trace, and abort the
>>> program.
>>>
>>
>> Alright, I think I see where the misunderstanding is coming from.
>>
>> I have only ever encountered (1).  And I've encountered it a lot.
>>
>> I didn't even consider (2) and (3) as possibilities.  Those are far  
>> from my mind.
>>
>> I still have a nagging doubt though: since the dereference in question  
>> is null, then there is no way for that particular dereference to  
>> corrupt other memory.  The only way this happens in (2) and (3) is that  
>> related code tries to write to invalid memory.  But if we have other  
>> measures in place to prevent that (bounds checking, other hardware  
>> signals, etc), then how is it still possible to corrupt memory?
>>
>>>
>>> [...]
>>>
>>> -Steve
>
> I spoke too soon!
> We missed one:
>
> 1. You forgot to initialize a variable.
> 2. Your memory has been corrupted, and some corrupted pointer
>   now points into no-mem land.
> 3. You are accessing memory that has been deallocated.
> 4. null was being used as a sentinal value, and it snuck into
>   a place where the value should not be a sentinal anymore.
>
> I will now change what I said to reflect this:
>
> I think I see where the misunderstanding is coming from.
>
> I encounter (1) from time to time.  It isn't a huge problem because  
> usually if I declare something the next thing on my mind is initializing  
> it.  Even if I forget, I'll catch it in early testing.  It tends to  
> never make it to anyone else's desk, unless it's a regression.   
> Regressions like this aren't terribly common though.  If you make my  
> program crash from (1), I'll live.
>
> I didn't even consider (2) and (3) as possibilities.  Those are far from  
> my mind.  I think I'm used to VM languages at this point (C#, Java,  
> Actionscript 3, Haxe, Synergy/DE|DBL, etc).  In the VM, (2) and (3)  
> can't happen.  I never worry about those.  Feel free to crash these in D.
>
> I encounter (4) a lot.  I really don't want my programs crashed when (4)  
> happens.  Such crashes would be super annoying, and they can happen at  
> very bad times.

You can use sentinels other than null.

-Steve


More information about the Digitalmars-d mailing list