Fantastic exchange from DConf

[Jack Stouffer via Digitalmars-d]

On Sunday, 14 May 2017 at 00:05:56 UTC, Dibyendu Majumdar wrote:
> (a) Trust the programmer.

That's the first and most deadly mistake. Buffer overflows and 
null pointers alone have caused hundreds of millions of dollars 
of damages. I think we can say that this trust is misplaced.

> (b) Don't prevent the programmer from doing what needs to be 
> done.

In reality this manifests as "Don't prevent the programmer from 
doing anything, especially if they're about to shoot themself".

See the code examples throughout this thread.

> (c) Keep the language small and simple.
> (d) Provide only one way to do an operation.

lol

> (f) Make support for safety and security demonstrable.

LOL http://article.gmane.org/gmane.comp.compilers.llvm.devel/87749

>My conclusion is that C, and derivatives like C++, is a very
>dangerous language the write safety/correctness critical software
>in, and my personal opinion is that it is almost impossible to 
>write
>*security* critical software in it.

(that's from the creator of clang btw)

> But I don't see how languages like D or Rust can replace C for 
> certain types of use cases.

Maybe you can argue for the use of C in embedded systems and in 
OS's, although I see no reason why Rust can't eventually overtake 
C there. However, much of the internet's security critical 
systems (openssl, openssh, DNS systems, router firmware) are in 
C, and if Google's Project Zero are any indication, they all have 
ticking time bombs in them.

As I stated earlier in the thread, at some point, some company is 
going to get sued for criminal negligence for shipping software 
with a buffer overflow bug that caused a security breach.

It almost happened with Toyota. The auto industry has a C coding 
convention for safety called MISRA C, and it was brought up in 
court as to why Toyota's acceleration problems were entirely 
their fault. You can bet this will be brought up again.