Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

What vulnerabilities does C introduce that C++ doesn't?


sort by: page size:

I'm more interested in the the actual statistics for security vulnerabilities found in C vs. C++ programmes, rather than theoretical benefits one language might have over the other.

The languages with the most security issues, by far, are C and C++.

C++ adds so many additional security footguns over C, that I find this line of reasoning hard to accept. The problem with C++ is not that people are using C constructs with it, the problem is that the language design itself is deficient.

Are you aware of any systematic review that shows evidence that C++ is safer than C?

The rate of safety defects between major C and C++ projects appears similar at first glance, and both way worse than managed languages or rust.


I can't see why C++ would be any safer than C. For example Heartbleed like bugs in C++ are still very much possible.

A lot of C's flaws are fixed in C++.

C++ adds a number of its own flaws, but that's beside the point when discussing C's flaws from a perspective of knowing C++.


I'm having some difficulty imagining that C is safer than C++.

Honestly these are issues introduced by C++, and avoidable by using C.

None of the safety issues brought up about C there are solved by C++. C++ is (nearly) a superset of C, so it inherits all of those issues.

Are you joking? Both C and C++ are equally littered with unsafe "features".

Not a useful comment, a better one /might/ be "don't write new software in c++."

But that said, C++ is safer than C.

This is a result of large and complex software developing features that require a large amount of manual and error prone code, whereas C++ can do the work for the developer, and will do it correctly everytime. Are there bad things in C++? of course. But you can avoid the known "bad" features - we can acknowledge things we originally thought would be good were in fact bad, and also recognize they need to remain due to old code - without throwing out all the good features.

Hence you get the "modern C++" subset that all serious large c++ projects use, which is not some horrific wasteland of bad code. Most security bugs that have been in C++ have been as a result of errors inherited from C and, unlike C, can be engineered out.

My suspicion is that the over-representation of C++ in vulnerability statistics is a product of the size of the major C++ codebases, the value of those targets, and the complexity of the products.


Interesting! Could you explain? What C features doesn't C++ have?

C++, especially when using features provided by the newest standards (C++11 and C++14), cannot be likened to C in terms of security problems. In theory, yes, it's backward compatible with C so any security issues present in C can be reconstructed in C++, but using managed pointers, standard containers, RTTI and other features can considerably reduce the attack surface... but I'd argue that not a great amount of applications could benefit from being written in C++ vs. some safer language.

That was kind of my point. I really think that if anything, C++ cannot be as unsafe as C. You can do crap in C++ just as well as you can do in C, but at least C++ gives you tools to do things way more safely IMO.

C++ offers safer constructs but they have their own sharp edges and you have to actually use them to get their benefits. In security critical software these can still be enough to cause significant problems.

And C++ is horrible for security. By default it inherits C's no-checks-at-all, give-me-performance-or-give-me-death mentality.

I disagree. First of all, most C code can be run as C++, so everything bad you can say about C applies to C++ as well. Second, C++ introduces its own problems that also make programming unsafe compared to other managed languages and even compared to C.

I, for one, see C as both unsafe and unergonomic. The many features of C++ can be seen as various attempts to make some or another thing expressible in C -- parameterized datatypes, namespacing, encapsulated resource management -- that wasn't before.

C++ has just as much capacity to be unsafe as C, precisely because it accepts nearly all C code, not to mention that it has bare pointers, null references, and any number of other unsafe objects as first-class citizens. Of course, you're unlikely to use most of those if you're following best practices, but the same can be said of C. You might argue that C++ makes it easier to be safe because of its plethora of features and classes, but the massive size of C++ makes it a very hard language to master, and nearly impossible to guarantee that everyone will be conforming to best practices. C++ is quite possibly the largest language out there in terms of features, and with about the most gotchas (things that don't work the way you'd intuitively expect them to) that it's possible to put in a language. It's a step above C in terms of safety, but it is hardly a safe language, and it's only slightly more productive, because the benefits of its class system and standard library are so much at odds with it's huge mental overhead.

I have to point out that the very name "C++" is a security vulnerability in said language.

I learned to program in C, during the dawn of the Internet. Yes, the "I can do anything on the machine" power was fun.

But when considering all C/C++ code is completely insecure by default, it really shouldn't be used to build anything new that processes untrusted input (which is just about everything). There are a few decades worth of mature alternatives that should be considered first, plus a few newcomers like Rust and golang.

next

Legal | privacy