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 11:58:08 UTC, Laeeth Isharc wrote:
> hog - maybe that is right, but in practice stuff written in 
> C,C++,D in a sensible, mature, thoughtful fashion but without 
> too much special effort given to optimisation seems to just run 
> fast without a need for tuning or any dark magic.  I am 
> probably not tuning it right, but even in 2015 one doesn't seem 
> to be impressed by the performance and memory efficiency of 
> Java apps.

Well, programs either run fast enough or not fast enough. If it 
runs fast enough or you run out of money, then you're done ;).

But "objectively fast" will have to be measured up to theoretical 
peak throughput (which you can calculate for a CPU). Most 
programs are nowhere close that since you need to be very careful 
with the size of the working set and layout in order to preload 
the cache, stay within cache level 1, store full cache lines, and 
keep all the "math units" (ALU ports) in the CPU busy.

The more abstraction levels you have, the more difficult it is to 
understand what will happen in the CPU (assuming you fully 
understand the internals of the _specific_ CPU, which changes 
from generation to generation).

>> 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.
>
> But commercial life is about trade-offs and pragmatic choices, 
> and the Pareto principle applies here too.  Ie I should think 
> the subset of reasonably secure, reasonably efficient systems 
> level programming is rather larger than the narrow domain you 
> speak of above.

Well, either the program is correct or it isn't.

The question is whether you want to detect it (trap on overflow), 
pretend it didn't happen (D style wrap around), assume it should 
not happen (gcc/clang at high optimization level), or prevent 
compilation until it is guaranteed not to happen.

In some domains it is best to halt when something wrong happens 
(before you sell all your stock at the wrong price?), in other 
domains you should keep going (serving ads), in yet other domains 
a rare crash is ok, but shoddy performance isn't (computer game 
with real time ray tracing)

> You have yourself suggested that if you want to use C and C++ 
> in a safe way then it comes at quite a price.

No, I suggested that if you pick C++ over Java for rational 
reasons you probably would get upset if you were told to use 
overflow trapping ints and GC by default in C++. The C++ default 
is based on what most people use C++ for.