Incorporating D

[Rainer Schuetze]

On 26.01.2013 16:53, deadalnix wrote:
> On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze wrote:
>>
>>
>> On 26.01.2013 11:40, Johannes Pfau wrote:
>>> 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.
>>>
>>
>> It is even dangerous if it is only used temporarily during that
>> function call, but copied elsewhere in the C heap and cleared on the
>> stack:
>>
>> struct param_struct { const char* name; };
>>
>> void c_function(const char*p)
>> {
>>     param_struct* ps = new param_struct;
>>     ps->name = p;
>>     p = 0;
>>     doSomething(ps);
>>     delete ps;
>> }
>>
>> Imagine a garbage collection while executing doSomething...
>
> That isn't an issue as the pointer will e found at upper level in the
> stack anyway.

"p = 0;" clears the only existing reference on the stack.