Scenario: OpenSSL in D language, pros/cons

[Daniele M. via Digitalmars-d]

On Sunday, 4 May 2014 at 13:29:34 UTC, Meta wrote:
> On Sunday, 4 May 2014 at 08:34:20 UTC, Daniele M. wrote:
>> I have read this excellent article by David A. Wheeler:
>>
>> http://www.dwheeler.com/essays/heartbleed.html
>>
>> And since D language was not there, I mentioned it to him as a 
>> possible good candidate due to its static typing and related 
>> features.
>>
>> However, now I am asking the community here: would a D 
>> implementation (with GC disabled) of OpenSSL have been free 
>> from Heartbleed-type vulnerabilities? Specifically 
>> http://cwe.mitre.org/data/definitions/126.html and 
>> http://cwe.mitre.org/data/definitions/20.html as David 
>> mentions.
>>
>> I find this perspective very interesting, please advise :)
>
> While D is a somewhat safer language by *default*, it makes it 
> fairly easy to escape from the safe part of the language and 
> write unsafe code (array bounds checking can be turned off even 
> for @safe code). Seeing as the OpenSSL devs went as far as to 
> write an a buggy, custom implementation of malloc for a speed 
> gain, turning off array bounds checking and ignoring @safe 
> seems like the first thing they would do. The only language I 
> would really trust is one in which it is impossible to write 
> unsafe code, because you can then know that the developers 
> can't use such unsafe hacks, even if they wanted to.

You are right, devs would eventually abuse everything possible, 
although it would make it for sure more visible: you cannot 
advertize an un- at safe library as @safe, although I agree that a 
lot depends from devs/users culture.