Chromium project finds that 70% of security defects are memory safety problems

Re:Chromium project finds that 70% of security defects are m... by josteink on Sunday May 24, 2020 @06:47AM (#23290662)

> Because this would refuse to compile 100% of real-world C++ code, so nobody would use it.

So if anyone is claiming you could write real-world safe C++ if you wanted to, they are making a false claim then?

[ Parent | on HN ]

Re:Chromium project finds that 70% of security defects are m... by the_why_of_y on Sunday May 24, 2020 @07:27AM (#23290794)

I think you'd have to do the same thing that you'd do in non-C++ languages: write an abstraction layer that encapsulates the low-level OS access (or hardware access, in embedded software) and whose implementation is unsafe, but whose interface is "safe", whatever that means.

Once you have that to build on top of, such a compiler flag could make sense... if it were possible in C++, which I'm not sure about.

See for example this criticism of one such effort: https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapour...

[ Parent | on HN ]

Re:Chromium project finds that 70% of security defects are m... by josteink on Sunday May 24, 2020 @08:05AM (#23290918)

So in about half a decade the C++ camp has made no improvements wrt to tooling and statically verified safe code, it’s been all talk and no show. And in the meantime Rust has improved massively.

It’s obviously still too early to declare a winner, but to me this sounds like a turtle slowly but surely overtaking a rabbit.

[ Parent | on HN ]