On Saturday, January 26, 2013 10:41:46 Johannes Pfau wrote: > Am Fri, 25 Jan 2013 22:38:51 +0100 > > schrieb "Jonathan M Davis" <[email protected]>: > > 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
