Incorporating D

Jonathan M Davis jmdavisProg at gmx.com
Sat Jan 26 02:19:02 PST 2013


On Saturday, January 26, 2013 10:41:46 Johannes Pfau wrote:
> Am Fri, 25 Jan 2013 22:38:51 +0100
> 
> schrieb "Jonathan M Davis" <jmdavisProg at gmx.com>:
> > On Friday, January 25, 2013 22:33:14 q66 wrote:
> > > > D's GC does not have serious problems. The only issue is
> > > > controversial status of GC.
> > > 
> > > D's GC has inherent issues with false positives, sometimes
> > > freeing memory that you don't really want freed, causing
> > > (sometimes hidden) bugs that are pretty much impossible to debug.
> > 
> > I've _never_ heard of it freeing something when it shouldn't.
> 
> I've seen that when porting GDC. Usually happens if the GC fails to
> scan the stack or more often it misses some TLS ranges. Never saw that
> with dmd though.
> 
> IIRC toStringz is also dangerous. You have to make sure that the C
> library does not store the pointer or also store it manually so the GC
> can find it. (This is not different from passing other C/D pointers, but
> with toStringz it's easy to miss).

Which is why the toStringz documentation points that out. The GC can only see 
what's referred to in the D code, not C code, so you have to make sure that 
the D code retains a reference to any pointers passed into C code or risk the 
GC thinking that it's okay to free it. But there really isn't any way around 
that, and it's completely different from the GC incorrectly thinking that a 
pointer was not referenced anywhere in D code and freeing it.

- Jonathan M Davis


More information about the Digitalmars-d mailing list