Incorporating D

[Johannes Pfau]

Am Sat, 26 Jan 2013 02:19:02 -0800
schrieb Jonathan M Davis <jmdavisProg at gmx.com>:

> > 
> > 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

Yes, I just wanted to point out a common source for such bugs, it's not
the GC's fault. It's great that the documentation of toStringz mentions
that issue. What I meant is most of the time we use toStringz() like
this:

string str;
c_function(str.toStringz());

This is only valid if c_function doesn't store the pointer, but newbies
might miss that and just copy this nice looking example code for other
c functions. There's nothing we can do about that though, interfacing
to C just is a little bit dangerous.