An idea to avoid a narrow class of bugs

deadalnix deadalnix at gmail.com
Mon Jun 25 06:17:57 PDT 2012


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.


More information about the Digitalmars-d mailing list