@safe leak fix?

[Denis Koroskin]

On Fri, 13 Nov 2009 14:50:58 +0300, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Thu, 12 Nov 2009 18:34:48 -0500, Jason House  
> <jason.james.house at gmail.com> wrote:
>
>> Steven Schveighoffer Wrote:
>>
>>> On Thu, 12 Nov 2009 08:45:36 -0500, Jason House
>>> <jason.james.house at gmail.com> wrote:
>>>
>>> > Walter Bright Wrote:
>>> >
>>> >> Jason House wrote:
>>> >> > At a fundamental level, safety isn't about pointers or references  
>>> to
>>> >> > stack variables, but rather preventing their escape beyond  
>>> function
>>> >> > scope. Scope parameters could be very useful. Scope delegates were
>>> >> > introduced for a similar reason.
>>> >>
>>> >> The problem is, they aren't so easy to prove correct.
>>> >
>>> > I understand the general problem with escape analysis, but I've  
>>> always
>>> > thought of scope input as meaning @noescape. That should lead to easy
>>> > proofs. If my @noescape input (or slice of an array on the stack) is
>>> > passed to a function without @noescape, it's a compile error. That
>>> > reduces escape analysis to local verification.
>>>
>>> The problem is cases like this:
>>>
>>> char[] foo()
>>> {
>>>    char buf[100];
>>>    // fill buf
>>>    return strstr(buf, "hi").dup;
>>> }
>>>
>>> This function is completely safe, but without full escape analysis the
>>> compiler can't tell.  The problem is, you don't know how the outputs  
>>> of a
>>> function are connected to its inputs.  strstr cannot have its  
>>> parameters
>>> marked as scope because it returns them.
>>>
>>> Scope parameters draw a rather conservative line in the sand, and  
>>> while I
>>> think it's a good optimization we can get right now, it's not going to
>>> help in every case.  I'm perfectly fine with @safe being conservative  
>>> and
>>> @trusted not, at least the power is still there if you need it.
>>>
>>> -Steve
>>
>> what's the signature of strstr? Your example really boils down to  
>> proving strstr is safe.
>
> The problem is, strstr isn't safe by itself, it's only safe in certain  
> contexts.  You can't mark it as @trusted either because it has the  
> potential to be unsafe.  I think if safe D heap-allocates when it passes  
> a local address into an unprovable function such as strstr, that's fine  
> with me.
>
> So the signature of strstr has to be unmarked (no @safe or @trusted).
>

Any example of how unsafe strstr may be? BTW, strstr is no different from  
std.algorithm.find:

import std.algorithm;

char[] foo()
{
     char[5] buf = ['h', 'e', 'l', 'l', 'o'];
     char[] result = find(buf[], 'e');

     return result.dup;
}

I don't see why a general-purpose searching algorithm is unsafe.