On Tuesday, 26 December 2017 at 11:54:12 UTC, codephantom wrote:
On Tuesday, 26 December 2017 at 10:00:25 UTC, Paolo Invernizzi
wrote:
IMHO, the lost list of vulnerability in code shipped by "first
class enterprises" is just crying out that C/C++ is not
mechanically checkable.
And we are talking about company that can literally spend an
Everest of money on that.
/Paolo
Well, the 'mechanics of checking' continue to need improvement,
whether it's C, C++, D, or whatever....
A language that is flexible enough to do the things you can do
with such a language, comes at a cost.. which is safety (or
program correctness to be precise). Flexibility breeds bugs!
That's just how it is. It's inescapable.
And I doubt that it has anything to do with how much money you
can spend.
In the example below, which is D code, I simply have to
'forget' to annotate with @safe, and then it's anyone's guess
at to what will happen (at least in the second example)
i.e. the mechanical checks don't occur because I simply
'forgot' to do something.
// ---
module test;
import std.stdio;
// from:
https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/
// look at how flexible D is...
void main()
{
auto buf = new int[1];
//buf[2] = 1; // compiles ok, even with @safe.
// but get range violation at runtime,
// whether you use @safe or not
// (unless you've disabled bounds checking)
buf.ptr[2] = 1; // compiles ok, runs ok - or does it?
// however, if you 'remember' to use @safe,
// then it won't compile, and you're safe.
}
// -----
I have to disagree, again.
It's factual that you can mechanically impose that a module
contains only @safe code, and you can do it in multiple ways. You
can 'mechanically' impose to write memory safe code in D.
With C/C++ you simply can't do it anything similar, today (and,
IMHO, neither tomorrow): the rising of Rust is here to tell us
exactly that.
/Paolo
