[Issue 4621] Destructors are inherently un-@safe
https://issues.dlang.org/show_bug.cgi?id=4621 Iain Buclaw changed: What|Removed |Added Priority|P2 |P3 --
[Issue 4621] Destructors are inherently un-@safe
https://issues.dlang.org/show_bug.cgi?id=4621 anonymous4 changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15595 --
[Issue 4621] Destructors are inherently un-@safe
https://issues.dlang.org/show_bug.cgi?id=4621 anonymous4 changed: What|Removed |Added Keywords||spec --
[Issue 4621] Destructors are inherently un-@safe
https://issues.dlang.org/show_bug.cgi?id=4621 anonymous4 changed: What|Removed |Added Keywords||safe Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #20 from anonymous4 --- AFAIK, the freed memory references are nor nullified. Another example: class A { @safe: int[] a; this(){ a=new int[1]; } ~this(){ a[0]=0; } //write after free } void f() @safe { auto a=new A; } --
[Issue 4621] Destructors are inherently un-@safe
http://d.puremagic.com/issues/show_bug.cgi?id=4621 --- Comment #19 from Michel Fortin 2013-08-05 17:13:32 EDT --- (In reply to comment #18) > This is invalid report since @safe has nothing to do with accessing > pointers/references which turned out to be nulls. Maxim, you're the first to mention null here. I'm not sure I get your point. This issue is about accessing destructed/deallocated memory from the destructor while GC is finalizing an object (or a struct on the GC heap). This can happen if you have a circular reference for instance, or anytime multiple objects that references themselves are finalized in the same pass. The most evil thing you could do is to leak a reference to the a finalized object to the outer world, and then you have a pointer to deallocated memory lying around somewhere. There's no way to catch any of this (currently), hence why destructors are unsafe (when called from the GC). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4621] Destructors are inherently un-@safe
http://d.puremagic.com/issues/show_bug.cgi?id=4621 Maxim Fomin changed: What|Removed |Added Status|NEW |RESOLVED CC||ma...@maxim-fomin.ru Resolution||INVALID --- Comment #18 from Maxim Fomin 2013-08-05 13:21:52 PDT --- This is invalid report since @safe has nothing to do with accessing pointers/references which turned out to be nulls. This is valid D code: void foo(int* p) @safe // or ref { *p = 0; } void main() @safe { foo(null); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---