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

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 14 July 2015 at 09:44:08 UTC, Ola Fosheim Grøstad 
wrote:
> 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.

Perhaps - I haven't measured these things myself, and don't 
recall downplaying of this in the short term I have been here, 
but I have no reason to think that's wrong.

But my point was one of good form.  You seemed to slam the 
original poster, who who made no stronger or more concrete 
assertion than that safety is a benefit of D [we surely know by 
now that linking to a piece implies endorsement of it only as 
being interesting, not more].  Perhaps that's a point 
well-founded in reality, but I didn't see you argue for it.

I have no interest in pursuing controversy further, but it really 
is a mystery to me as to why you don't do something constructive 
towards shaping the world as you would like to see it.  Code wins 
debates, and a DIP is less work than implementing the whole thing 
oneself.  It is of course possible there is background to which I 
am not privy, and that that is why it is mysterious.

> 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.

I'll certainly take programmer productivity if I don't need to 
pay too much for it, and if the aesthetic experience of getting 
my stuff done can be made something pleasurable.  I am not sure 
however if you are making an argument to justify your implicit 
position, since it seems we both have similar assessments of C++ 
as its used, or easy to use.  I do not think it is controversial 
either to observe that C++ has more options!

Life in the commercial world involves pragmatic choices.  So the 
missing piece in your argument would be to demonstrate that 
programmer productivity ('convenience') and non-tedious syntax 
are not all that important.  Conventional wisdom seems to be that 
productivity matters more than efficiency (personally I don't 
mind trading off a little, but there are limits!)

> 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.

I don't know - I think there are many factors that go into such a 
decision.  It's a big world, and I wouldn't pretend to know what 
shapes problems in different domains.  What is discussed in the 
media is not necessarily representative of what actually goes on 
amongst people quietly getting their work done.  I am told that 
Java is often faster than C++ and needn't be a memory 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.

> 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.

Do you need to in the whole part of what you are writing, and if 
you do, are you in the same boat?

> 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.

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

I don't know what "systems programming" means any more, only what 
it meant 30 years ago.  Wouldn't you say that Weka, Sociomantic, 
possibly the guys doing the Norwegian subway announcement system 
have at least aspects of system level programming and can be 
described as critical?  The hedge fund about which Andy Smith 
spoke - their application may or may not be systems level, but it 
strikes me as not so far from that.

> 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.

A rebuttal would have been to demonstrate that the OP was making 
a silly point that cannot be justified.  You have yourself 
suggested that if you want to use C and C++ in a safe way then it 
comes at quite a price.  Commercial adoption is after all driven 
by these sorts of things.