You must log in or register to comment.
Honestly his defence is rather weak. “It’s been improving and there are ways to use it safely.”
That is not to say I agree with the administration’s statement. Not only is secure code only one aspect among a myriad to consider when choosing a language, using a “safer” language does not necessarily lead to more secure code.
Yeah, I like his argument about profiles maybe going to be able “e.g., to eliminate most range errors relatively soon.”
Well maybe C++ could be considered safe “relatively soon” then but not right now.
Like he says: “Of the billions of lines of C++, few completely follow modern guidelines, and peoples’ notions of which aspects of safety are important differ.”
That said, I don’t really consider C++ to be inherently unsafe, there’s a lot that goes into secure programming in any language. Just because you can’t write to an array out of bounds in python doesn’t mean your code is magically immune to vulnerabilities and just because you can in C, it doesn’t mean your code is magically vulnerable to RCE from some buffer overflow.
I also don’t really trust myself to write perfectly safe production C++ though. I feel like it’s still too easy to feel like you know exactly what you’re doing and accidentally miss something small (hence the many thousands of memory safety CVEs in professional software).
Honestly his defence is rather weak. “It’s been improving and there are ways to use it safely.”
I think it’s a very good and clear point to make.
Some programming languages are blindly deemed “safe” in spite of supporting unsafe memory management strategies, and somehow not enforcing those rules does not render them unsafe.
Why is this logic not applied to C++?
Unsafe code, at least in Rust, is given special treatment and care. Such code is usually 5% or less of the total codebase. Such unsafe blocks are also commonly reused fundamental designs. This leads to them being designed as libraries that are shared.
You can of course give C++ the same consideration. But then 100% of that code base will have to be given special care. And the reusability of unsafe code goes out the window.
People who argue that Rust (not sure about GC languages) is equivalent to C and C++ because of escape hatches like unsafe, completely neglect the localization of unsafe code and the benefits it brings.
Some programming languages are blindly deemed “safe” in spite of supporting unsafe memory management strategies, and somehow not enforcing those rules does not render them unsafe.
You’re applying a strawman argument here, because nobody is blindly deeming any languages as safe. But they are recognizing some languages as safer than others. Safety isn’t a binary switch, and most people recognize that. Most people also recognize that using tools that make it harder to achieve safety, does, in fact, make it harder to achieve safety. And thus, if safety is important, avoiding those tools makes perfect sense.
“I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees,”
My impression is that they are very aware of the state of C++ and the efforts to provide strong safety guarantees. That’s why they keep raising the pressure.
I have worked with fairly large c++ codebases: It’s totally possible to write much safer code than it ever was and I actually enjoy modern c++. Still it’s still a burden and mishaps can and will happen. The time for the c++ committee to show they can overcome the language’s issues has passed IMHO there are much better, and more expressive, alternatives.
I don’t believe in the whole model of releasing a standard every 3 years and then taking who knows how long to implement it, and not braking compatibility. that shit just hinders the language. With all this said I don’t think c++ is going to die any time soon.
The time for the c++ committee to show they can overcome the language’s issues has passed IMHO there are much better, and more expressive, alternatives.
I’m not sure if this is a good take.
Languages deemed “safe” boil down to two features: supporting specific memory management strategies, and adding static code analysis checks that enforce rules and best practices.
Can’t this be done already without involving committees?
That works only if memory safety is optional. Additions of the language features needed for mandatory memory safety are backwards incompatible.
deleted by creator
C++ can be written to be safe. I don’t think WH is the right authority to issue this warning. Naming C++ rather than going after specific features is unfair.
That said, writing safe C++ requires a good training, and I’ve seen many colleagues who don’t / can’t write safe C++. I don’t think my company has the skill. I don’t think I can fix my company. Also, the safety in C++ breaks down the moment someone links to an unsafe library. C++ does not really offer language support for analyzing what’s safe and what’s not.
We all knew Stroustrup was going to defend C++. I have read him do so a few times in the past. Imho he always does make a point. But I’ve never seen him admit any weakness. I’ve never seen a non-C++ dev see his comments and change their mind.
C++ can be written to be safe. I don’t think WH is the right authority to issue this warning. Naming C++ rather than going after specific features is unfair.
I suspect that the white house just received a report from some people in the industry stating that faulty software is vulnerable to attacks from bad actors, and from that basis they just went the simplistic path of arguing that 1) lots of software is written in C++, 2) that software has bugs, therefore if we don’t use C++ then we won’t have bugs.
As a branch of government, their role is not to evaluate technical merits of proposals but to hear what their representatives have to say.
One of their sources is the NSA, which is both mandated to make such recommendations and has the competence to do so. And as for the safety of C++, it’s possible to write unsafe code in modern C++. One of the best examples is multithreaded code. Modern C++ is far safer than C or pre-C++11, but it doesn’t address the entire space of memory safety.
