@safe leak fix?

[Jason House]

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

I disagree. Borrowing the syntax from the return const proposal, let's define strstr as follows:
inout(char[]) strstr(inout(char[]) buf, const(char[]) orig);

What I want that to tell the compiler is that buf, or some piece of buf, is returned from strstr. (please don't assign any more meaning than that, i.e. constness of buf). The compiler would then treat the return value with the same protection as buf, and a return without .dup is a compile error.

I've been in drawn out discussions with you before. If this post and my prior post don't make you budge from your position than I'll simply give up trying to convince you. It's not worth the aggregation.