@safe leak fix?

[Steven Schveighoffer]

On Fri, 13 Nov 2009 07:01:25 -0500, Denis Koroskin <2korden at gmail.com>  
wrote:

> 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?

Sure (with the current compiler):

char[] foo()
{
   char buf[100];
   // fill buf
   return strstr(buf, "hi"); // no .dup, buf escapes
}

The whole meaning of safe is fuzzy, because we don't know the safe rules  
with regards to passing references to local data.  But I think the goal is  
to make it so strstr can be marked as safe.  In order to do that, foo must  
be required to be unmarked or @trusted, or foo allocates buf on the heap.

The point I was trying to make to Jason is that escape analysis is more  
complicated than just marking parameters as @noescape -- you leave out  
some provably safe functions.

> 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.

It isn't inherently unsafe.  It's just difficult for the compiler to see  
just from a function signature where the data flows, and escape analysis  
requires full data-flow disclosure.  I think with Walter's proposal of  
allocating when a @safe function passes an address to a local to another  
@safe function is perfectly acceptable to me.  I'd also like to see cases  
where you can mark the input parameter as scope, potentially optimizing  
out the allocation (but then you cannot return the scope parameter or a  
reference to any part of it).

-Steve