[Issue 4621] Destructors are inherently un-@safe

[d-bugmail--- via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

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

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=4621

anonymous4  changed:

   What|Removed |Added

   Keywords||spec

--

[Issue 4621] Destructors are inherently un-@safe

[via Digitalmars-d-bugs]

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

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4621


Maxim Fomin ma...@maxim-fomin.ru changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ma...@maxim-fomin.ru
 Resolution||INVALID


--- Comment #18 from Maxim Fomin ma...@maxim-fomin.ru 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: ---

[Issue 4621] Destructors are inherently un-@safe

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=4621



--- Comment #19 from Michel Fortin michel.for...@michelf.com 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: ---