The "@safe vs struct destructor" dilemma

[Michel Fortin]

On 2014-04-12 10:29:50 +0000, "Kagamin" <spam at here.lot> said:

> On Saturday, 12 April 2014 at 03:02:56 UTC, Michel Fortin wrote:
>> 2- after the destructor is run on an object, wipe out the memory block 
>> with zeros. This way if another to-be-destructed object has a pointer 
>> to it, at worse it'll dereference a null pointer. With this you might 
>> get a sporadic crash when it happens, but that's better than memory 
>> corruption.
> 
> Other objects will have a valid pointer to zeroed out block and will be 
> able to call its methods. They are likely to crash, but it's not 
> guaranteed, they may just fine corrupt memory. Imagine the class has a 
> pointer to a memory block of 10MB size, the size is an enum and is 
> encoded in the function code (won't be zeroed), the function may write 
> to any region of that block of memory pointed to by null after the 
> clearing.

Well, that's a general problem of @safe when dereferencing any 
potentially null pointer. I think Walter's solution was to insert a 
runtime check if the offset is going to be beyond a certain size. But 
there has been discussions on non-nullable pointers since then, and I'm 
not sure what Walter thought about them.

The runtime check would help in this case, but not non-nullable pointers.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca