Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++

[via Digitalmars-d]

On Tuesday, 14 July 2015 at 08:54:42 UTC, Laeeth Isharc wrote:
> Now one may say that this isn't all he was saying, that the GC 
> in D can be improved, that D could be safer, and so on.  But 
> it's hardly fair to suggest the original poster is not right 
> about one of the advantages of D vs C and C++.

The linked webpage explicitly states that C UB for integer 
overflow gives 2x performance in some scenarios. Something these 
forums have tried to play down many times.

You have compiler-options/libraries/tools for C++ that allows you 
to write as safe and safer code than D (which lacks sanitizers) 
at the cost of performance and convenience. Just like D defaults 
sacrifice performance for the same, but D tries to give priority 
to convenience. Which C++ does not have much of (convenience that 
is). C++ has an impressive range of options that beats all 
alternatives in the flexibility-department, but also high 
complexity levels and tedious syntax.

It is just that if you use C++ over Java you do it because you 
need performance and deliberately through-and-through avoid those 
features/library/compiler options/tools and resort writing code 
that is less robust. My C++ libraries do void casts and lots of 
other low level stuff, not because C++-eco system does not 
provide robust alternatives, but in order to work with raw 
memory. I would never dream of doing that in a language like Go 
or Java. I do it because I _need_ the performance that C/C++ 
brings and also need to tailor low level constructs/hardware/OS. 
Which I could not do at all in Go/Java.

If you do the same in D, you are in the same boat as C++, except 
C++ is more tedious and C++ provide sanitizers.

But there are restricted and annotated versions of C that offers 
provable safety at the cost of development time, but with C 
performance. Thus is much better than D for _secure_ performant 
system level programming since you also have both termination and 
run-time guarantees.

Of course, nobody use D for critical system level programming, so 
that is not really an issue in the forseeable future.

Good enough rebuttal? Slamdunk C/C++ for the right reasons: 
complexity and tedium. Complexity and tedium make people more 
likely to make fatal mistakes... but that's ergonomics, not 
semantics.