Null references redux

[Jeremie Pelletier]

Max Samukha wrote:
> Lionello Lunesu wrote:
> 
>> On 27-9-2009 9:20, Walter Bright wrote:
>>> language_fan wrote:
>>>> The idea behind non-nullable types and other contracts is to catch
>>>> these errors on compile time. Sure, the code is a bit harder to write,
>>>> but it is safe and never segfaults. The idea is to minimize the amount
>>>> of runtime errors of all sorts. That's also how other features of
>>>> statically typed languages work.
>>>
>>> I certainly agree that catching errors at compile time is preferable by
>>> far. Where I disagree is the notion that non-nullable types achieve
>>> this. I've argued extensively here that they hide errors, not fix them.
>>>
>>> Also, by "safe" I presume you mean "memory safe" which means free of
>>> memory corruption. Null pointer exceptions are memory safe. A null
>>> pointer could be caused by memory corruption, but it cannot *cause*
>>> memory corruption.
>> // t.d
>> void main()
>> {
>>     int* a;
>>     a[20000] = 2;
>> }
>>
>> [C:\Users\Lionello] dmd -run t.d
>>
>> [C:\Users\Lionello]
>>
>> This code passes on Vista. Granted, needs a big enough offset and some
>> luck, but indexing null will never be secure in the current flat memory
>> models.
>>
>> L.
> 
> That is a strong argument. If an object is big enough, modifying it via a 
> null reference may still cause memory corruption. Initializing references to 
> null does not guarantee memory safety.

How is that corruption? These pointers were purposely set to 0x00000002, 
corruption I believe is when memory is modified without the programmer 
being aware of it. For example if the GC was to free memory that is 
still reachable, that would cause corruption.

Corruption is near impossible to trace back, this case is trivial.