On Friday, 18 October 2013 at 09:10:30 UTC, John Colvin wrote:
On Friday, 18 October 2013 at 06:26:51 UTC, Maxim Fomin wrote:
On Thursday, 17 October 2013 at 23:25:52 UTC, Meta wrote:
On Thursday, 17 October 2013 at 23:18:21 UTC, DDD wrote:
I tried this code and the compiler allowed it (runtime I get
object.Error: Access Violation). What am I doing wrong?
Thanks I didn't notice
@safe
import std.stdio;
class A {
int x = 1;
}
@safe void main() {
A a;
a.x=9;
}
This is more or less a different thing. SafeD doesn't
guarantee that your class references will not be null. Trying
to call a method on a null reference is perfectly valid in
SafeD. There's a pull request sitting in GitHub for a NotNull
type that should be reasonable good for ensuring that your
references are not null, but it hasn't been pulled yet.
Actually on linux this will segfault so in general this is not
safe across all platforms.
It's still memory safe in the sense that it's guaranteed to not
stomp on anything -> no silent corruption.
Well, in some sence yes. The problem with dereferencing nulls is
that behavior is different in linux and windows (i.e. non
portable), but you can enable treating nulls as exception in
linux if you use etc.linux.memoryerrors.
I don't really think the distinction between an Error or a
segfault is the dividing line between safe and not safe. Both
are supposed to be (under 99.9% of circumstances) unrecoverable
errors.
Some errors are propagated as exceptions, some errors are handled
like abort, so situation depends on type of the error. Users are
not supposed to catch errors, but they still can, which makes
situation is compilcated in general.
However, dereferencing null is tiny problem comparing to other
issues in D's safity.
