@safe leak fix?

[Denis Koroskin]

On Fri, 13 Nov 2009 16:16:29 +0300, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Fri, 13 Nov 2009 07:46:02 -0500, Denis Koroskin <2korden at gmail.com>  
> wrote:
>
>
>>> Sure (with the current compiler):
>>>
>>> char[] foo()
>>> {
>>>    char buf[100];
>>>    // fill buf
>>>    return strstr(buf, "hi"); // no .dup, buf escapes
>>> }
>>>
>>
>> No, no, no! It's foo which is unsafe in your example, not strstr!
>
> OK, tell me if foo is now safe or unsafe:
>
> @safe char[] bar(char[] x);
>
> char[] foo()
> {
>    char buf[100];
>    return bar(buf);
> }
>

It is unsafe even if bar doesn't return anything (it could store reference  
to a buf in some global variable, for example). Or accessing globals is  
considered unsafe now?

It is foo's fault that pointer to a stack allocated buffer is passed and  
returned outside of the scope. The dangerous line is buf[], which gets a  
slice out of a static array, not return bar(...). You could as well write:

char[] foo()
{
     char buf[100];
     return buf[]; // no more bar, but code is still dangerous
}