5 ms·

If you want to use statistics to support your assertion that C++ hasn’t gotten better, safer and more efficient over the decades then your statistics must compa

by blub 4y ago

If you want to use statistics to support your assertion that C++ hasn’t gotten better, safer and more efficient over the decades then your statistics must compare different versions of C++, not C++ and Rust. The blog you linked to is a PR piece. A real study would go in-depth and look at the quality of the C and C++, particularities of the affected subsystems (such as a requirement to interact directly with HW, etc), split findings by subsystem and components and also link snippets of source code to CVEs. Hopefully Google will publish such a study someday instead of a few pieces of data and graphs. But that’s not the major issue. You’re taking as fact that Google’s Android C++ programmers are particularly interested in safety or are significantly more competent than average. Based on my occasional perusal of Android C++ code in a professional context I cannot confirm either assumption: Android C++ is not modern (not even C++11 modern) and is very pointer heavy. It’s an eclectic mix of C functions and C data types with C++ constructs. Take a look at some random fixes for CVEs that I took from the December security bulletin: * https://android.googlesource.com/platform/frameworks/minikin/+/b215af1ecb2d5e9cec23444978fccc72d3821c98%5E%21/#F0 https://android.googlesource.com/platform/frameworks/minikin... * https://android.googlesource.com/platform/packages/modules/Bluetooth/+/6b4acc4d439bf6e66c520819de068eb486724e05%5E%21/#F0 https://android.googlesource.com/platform/packages/modules/B... * https://android.googlesource.com/platform/packages/modules/Bluetooth/+/644f250acd25ef47950c39349eea6fbfbdd41c14%5E%21/#F0 https://android.googlesource.com/platform/packages/modules/B... That looks like C with classes to me. Perhaps it’s for the best if projects such as Android or Chrome, etc are rewritten in Rust. Catching stuff after the fact with sanitizers, fuzzing, etc will never work if the code is ignoring or can’t use most of the advances that Stroustrup was talking about.

pjmlp 4y ago
Google's code bases (and Microsoft as well), are a good example of even ISO C++ members, major contributors to C++ compiler ecosystem and static analysis tooling, still fail to achieve the security standards that Bjarne Stroustrup and other security minded folks keep advocating for. Mostly because in the end they aren't doing what gets preached in spite of the in-house experts. So how much hope have the regular C++ devs that don't take part in ISO C++ and compiler development tasks?
- zozbot234 4y ago
  That's the really nice part of Rust, actually. The compiler will always barf if you don't do the right thing in Safe Rust, even by mistake. And even common but logically error-prone patterns, such as shared mutability, are clearly marked by boilerplate.
  - pjmlp 4y ago
    Nice part of any safe systems language, not only Rust.
- blub 4y ago
  Google is too big, working on too many projects which are released too often for the tools and processes to keep pace. They additionally have high turnover. Under these circumstances, using C++ over decades has the results that can be seen - they can’t produce secure software. I don’t think that Google or any other company can create secure products. I was actually surprised how many Java bugs were present in the December list. The market, the incentives are not set up for that. Sure, using safe languages would help in a narrow sense, why not give it a try, but this is turning into scapegoating and silver bullet activism. Once they get rid of the most C and C++ code I bet their products will still be insecure, because the culture, the processes, the market and the people won’t have changed.
  - pjmlp 4y ago
    Ah, the typical when we get rid of the 70% memory corruption bugs, we still have to deal with the remaining 30%, so why bother.
    - blub 4y ago
      By all means, bother with that and implement it. Then publish a proper study, so others could learn from it.
      - pjmlp 4y ago

by blub 4y ago

pjmlp 4y ago

Google's code bases (and Microsoft as well), are a good example of even ISO C++ members, major contributors to C++ compiler ecosystem and static analysis tooling, still fail to achieve the security standards that Bjarne Stroustrup and other security minded folks keep advocating for. Mostly because in the end they aren't doing what gets preached in spite of the in-house experts. So how much hope have the regular C++ devs that don't take part in ISO C++ and compiler development tasks?

zozbot234 4y ago
That's the really nice part of Rust, actually. The compiler will always barf if you don't do the right thing in Safe Rust, even by mistake. And even common but logically error-prone patterns, such as shared mutability, are clearly marked by boilerplate.
- pjmlp 4y ago
  Nice part of any safe systems language, not only Rust.
blub 4y ago
Google is too big, working on too many projects which are released too often for the tools and processes to keep pace. They additionally have high turnover. Under these circumstances, using C++ over decades has the results that can be seen - they can’t produce secure software. I don’t think that Google or any other company can create secure products. I was actually surprised how many Java bugs were present in the December list. The market, the incentives are not set up for that. Sure, using safe languages would help in a narrow sense, why not give it a try, but this is turning into scapegoating and silver bullet activism. Once they get rid of the most C and C++ code I bet their products will still be insecure, because the culture, the processes, the market and the people won’t have changed.
- pjmlp 4y ago
  Ah, the typical when we get rid of the 70% memory corruption bugs, we still have to deal with the remaining 30%, so why bother.
  - blub 4y ago
    By all means, bother with that and implement it. Then publish a proper study, so others could learn from it.
    - pjmlp 4y ago