Am Sat, 26 Jan 2013 02:19:02 -0800 schrieb Jonathan M Davis <[email protected]>:
> > > > 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.
