On Saturday, 1 June 2013 at 20:31:45 UTC, monarch_dodra wrote:
On Saturday, 1 June 2013 at 20:22:01 UTC, Nick Sabalausky wrote:
Core dumps aren't the big problem @safe tries to avoid. The
big problem
is memory corruption, ie trampling memory you didn't expect to
(or
shouldn't be allowed to).
So, let's say I have:
--------
void foo(int* p) @safe
{
*p = 0;
}
--------
I don't see how this is related to @safe. Remove the attribute,
and you are in same situation.
I suppose that this give foo the liberty of saying "p points to
someplace valid" ... "and if not, it's not my fault"?
I think in D any reference or pointer may refer to anywhere.
Actually, example above is not a big deal. Example of bigger
problem:
extern(C) int printf(const char*,...) @safe;
alias int T;
auto foo(lazy T i) @safe
{
return { return i; } ;
}
auto bar() @safe
{
T i = 4;
return foo(i);
}
void baz() @safe
{
double[2] i = 3.14;
}
void main() @safe
{
auto x = bar();
baz();
printf("%d\n", x());
}
This may print garbage or not, it also can print constant garbage
or changing, depending on compiler switches. Assume that foo, bar
and baz are splitted in several modules and instead of int there
is more complex data structure. This is example of memory error
not prevented by @safe.
