On Fri, 13 Nov 2009 14:50:58 +0300, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Thu, 12 Nov 2009 18:34:48 -0500, Jason House
<jason.james.ho...@gmail.com> wrote:
Steven Schveighoffer Wrote:
On Thu, 12 Nov 2009 08:45:36 -0500, Jason House
<jason.james.ho...@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.
