An idea to avoid a narrow class of bugs

[Alex Rønne Petersen]

On 25-06-2012 15:17, deadalnix wrote:
> Le 25/06/2012 13:35, bearophile a écrit :
>> I've suggested to add a little piece of static analysis inside the D
>> compiler, able to catch all cases of a specific kind of bugs:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=8293
>>
>>
>> A short thread in D.learn about a
>> core.exception.InvalidMemoryOperationError:
>> http://forum.dlang.org/thread/js649p$1707$1@digitalmars.com
>>
>> Caused by this code:
>>
>> class X {
>>      string[string] s;
>>      this() {
>>          s["s"] = "S";
>>      }
>>      ~this() {
>>          s.remove("s");
>>      }
>> }
>> void main() {
>>      X x = new X();
>> }
>>
>>
>>
>> Jonathan M Davis:
>>
>>> you should never do anything in a class' destructor/finalizer which
>>> could ever trigger the GC in any way.
>>
>> In past I have seen other similar bugs discussed in D.learn.
>>
>> I think a small amount of static analysis code added to the D front-end
>> can statically avoid every bug of this kind. This code has to look
>> inside ~this(){} and work recursively (like purity and nothrow
>> enforcement do), searching for functions that perform GC activity.
>>
>> (This is a bit different from the enforcement of the @noheap annotation
>> I have suggested in Issue 5219 because it's OK to manage C-heap memory
>> inside the destructor, while @noheap looks for C-heap activity too
>> (malloc/realloc/calloc)).
>>
>> Bye,
>> bearophile
>
> To me, it is a GC implementation issue. You should be able to allocate
> in destructors.

Yes, I don't understand why on earth this limitation is in place. There 
is no (good) technical reason it should be there.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org