On 2/27/15 7:33 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Feb 27, 2015 at 06:02:57AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[...]
Safety is good to have, and the simple litmus test is if you slap
@safe: at the top of all modules and you use no @trusted (or of course
use it correctly), you should have memory safety, guaranteed.
[...]
@safe has some pretty nasty holes right now... like:
https://issues.dlang.org/show_bug.cgi?id=5270
https://issues.dlang.org/show_bug.cgi?id=8838
https://issues.dlang.org/show_bug.cgi?id=12822
https://issues.dlang.org/show_bug.cgi?id=13442
https://issues.dlang.org/show_bug.cgi?id=13534
https://issues.dlang.org/show_bug.cgi?id=13536
https://issues.dlang.org/show_bug.cgi?id=13537
https://issues.dlang.org/show_bug.cgi?id=14136
https://issues.dlang.org/show_bug.cgi?id=14138
There are probably other holes that we haven't discovered yet.
Yah, @safe is in need of some good TLC. How about we make it a priority
for 2.068?
All in all, it's not looking like much of a guarantee right now. It's
more like a cheese grater.
This is a symptom of the fact that @safe, as currently implemented,
starts by assuming the whole language is @safe, and then checking for
exceptions that are deemed unsafe. Since D has become quite a large,
complex language, many unsafe operations and unsafe combinations of
features are bound to be overlooked (cf. combinatorial explosion), hence
there are a lot of known holes and probably just as many, if not more,
unknown ones.
I'd have difficulty agreeing with this. The issues you quoted don't seem
to follow a pattern of combinatorial explosion.
On another vein, consider that the Java Virtual Machine has had for
many, many years bugs in its safety, even though it was touted to be
safe from day one. With each of the major bugs, naysayers claimed it's
unfixable and it belies the claim of memory safety.
A @safe function may assume that the code surrounding it has not broken
memory integrity. Under that assumption, it is required (and
automatically checked) that it leaves the system with memory integrity.
This looks like a reasonable stance to me, and something I'm committed
to work with.
Trying to fix them is like playing whack-a-mole: there's
always yet one more loophole that we overlooked, and that one hole
compromises the whole system. Not to mention, every time a new language
feature is added, @safe is potentially compromised by newly introduced
combinations of features that are permitted by default.
There aren't many large features to be added, and at this point with
@safe being a major priority I just find it difficult to understand this
pessimism.
Probably a good thing to do, whether you're right or overly pessimistic,
is to fix these bugs. In the worst case we have a slightly tighter
"cheese grate". In the best case we get to safety.
Rather, what *should* have been done is to start with @safe *rejecting*
everything in the language, and then gradually relaxed to permit more
operations as they are vetted to be safe on a case-by-case basis.
Yah, time travel is always so enticing. What I try to do is avoid
telling people sentences that start with "You/We should have". They're
not productive. Instead I want to focus on what we should do starting now.
See: https://issues.dlang.org/show_bug.cgi?id=12941
I'm unclear how this is actionable.
Andrei
