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 13:28:44 UTC, Ola Fosheim Grøstad 
wrote:
> 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.

I also think UB is acceptable as long as the triggering 
conditions are clear, well understood, and it has a raison 
d'etre. Often this is allowing more aggressive optimizations.

I don't think you can always trade these sort of abstractions or 
compiler aid for performance. Sometimes you need to ensure 
security, performance, and readability/maintainability, all by 
yourself, the hard way, by trading in developer time. Many people 
are willing to do so, and many companies depend on this, because 
that is the only way to do it in the present, with the current 
hardware and/or budget constraints.
Sometimes even with decades old hardware constraints - anyone 
familiar with the demoscene? :)

My point is that there are also many developers out there, for 
whom a language with no undefined behavior, and theoretically 
sound is not appealing at all, if those feature put any sort of 
barriers on getting the most out of the hardware.

I do have the feeling, perhaps wrongly, that there aren't many on 
these forums, though, given the direction of most discussions.