Incorporating D

[Walter Bright]

On 1/26/2013 8:17 AM, Rainer Schuetze wrote:
>
>
> 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.

No, because ps is on the stack, and ps points to a copy of p. Hence, that code 
snippet is GC safe.