[OT] - A hacker stole $31M of Ether — how it happened, and what it means for Ethereum
Maksim Fomin via Digitalmars-d
digitalmars-d at puremagic.com
Fri Aug 4 02:26:31 PDT 2017
On Friday, 4 August 2017 at 08:46:05 UTC, Walter Bright wrote:
> On 8/4/2017 1:33 AM, RazvanN wrote:
>> That could have never happened if they would have used D with
>> @safe
>
> That's mostly true, but not absolutely true.
>
> 1. There can be bugs in D's @safe checking and inference.
>
> 2. Function interfaces (such as in C interface files) are
> labeled @safe or not, and the D compiler has no way to check.
> Hence, functions can (and have been) mislabeled.
>
> On the other hand, @safe does greatly reduce the attack
> surface. And as I've prognosticated before, the utter lack of
> machine checkable memory safety in C will herald the end of its
> use in anything connected to the internet.
So, you agree that @safe cannot solve the problem because of C
function interfaces and 'lack of machine checkable memory safety
in C'. In this case, why does @safe relies on static analysis in
CT and type inference when memory safety is determined by the 'C
memory sate' at RT? Either @safe is wrongly presented (it is not
memory safety tool, but something else) or (if the intention was
to provide memory safety tool) it is a flawed feature.
Of course, memory safety is impossible in C. In my opinion, D's
@safe is wrongly marketed as a fully safety tool (look at a user
above). This is dangerous, because leads to unfounded assumptions
and later disappointment.
By the way, I see that DIP 100 followed the same way - impose
static type restrictions in CT to prevent memory errors. I
believe, due to growing language complexity any combination of
resctrictions can have loopholes. Back in 2013 I was collecting
type system holes and posted them in Bugzilla after your request.
It appears, that scope has its own loopholes too [1].
[1] https://issues.dlang.org/show_bug.cgi?id=17718
More information about the Digitalmars-d
mailing list