On Monday, 14 April 2014 at 23:44:47 UTC, Steven Schveighoffer
wrote:
On Mon, 14 Apr 2014 19:28:06 -0400, lzzll <[email protected]>
wrote:
Looks like dangling point is not checked even in method mark
as safe.
Example:
---
import std.stdio;
class A {
int value;
void set_value(int value) @safe {
this.value = value;
}
}
void test_safe(A a) @safe {
a.set_value(1);
}
int main(string[] args) {
A a = new A();
test_safe(a);
test_safe(null);
test_safe(*(&a+100));
writeln("done.");
return 0;
}
---
test_safe(null);
and
test_safe(*(&a+100));
will cause segmentation fault.
Safe cannot verify its inputs. main() is not marked as safe,
therefore it will not help.
But even so, dereferencing null is @safe, since it does not
corrupt memory. Your *(&a + 100) will definitely not compile if
main is marked @safe.
-Steve
That's correct.
Let me ask:
1. That's mean if I write a safe library and another guy use it
in the wrong way, it still not really safe, right?
2. In the real world use, if I received a segmentation fault that
mean I had to get the core dump and trace where is the problem,
that's all right. But if I not received anything but actually the
bad memory has been write or leak, that's the security issue.
3. I hope it will be truly safe in the future, prevent the access
to dangling pointer, is there any plan or idea for this?
