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.
