@safe leak fix?

[Steven Schveighoffer]

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

> You're implying that the return of buf from strstr is unsafe. Indeed, my  
> intentionally short post didn't discuss returning from functions.  
> Ignoring that for a moment, surely you'd agree the following is safe:
>
> char[] foo(){
>     char[100] buf;
>     copystringintobuf(buf, "hi");
>     return buf[0..2].dup;
> }
>
> As far as return types, there are two subtle issues:
> 1. Returned input argument must preserve the scope requirements of the  
> caller. A similar problem as return variables and const annotation.
> 2. Unlike const annotations, there is more than three states for scope,  
> it's simply a measure of how deep/shallowvariables can be in the stack.

Yes, but I think such an annotation system is unworkable.  I'd rather see  
the compiler annotate into an intermediate file.  Even with those, you  
would be hard pressed to be able to prove all cases when the scope depth  
depends on runtime values.  That would require runtime checks.  I think  
escape analysis is a worthy goal, but very hard to implement.  Just  
allocating when you can't prove anything is a decent solution.

-Steve