[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