On 04/23/2013 11:36 PM, Kevin Kofler wrote:
Moving from C/C++ to a slower language is neither helpful nor necessary. If you really want full bound checking, it can be added to C/C++ rather than moving to a completely different language, and you'd still get the other benefits of C/C++, in particular, fast native code. It shouldn't be worse for peformance than switching to another language: After all, the other languages have to do the bound checking as well!
At least you can avoid pointless discussions with developers if the overhead is unavoidable. 8-/
I shall also note that vulnerable C++ code is mainly code which uses C-style data structures for whatever reason (often, interfacing with C-only libraries). If we all wrote pure Qt code, there would be little to no buffer overflow vulnerabilities. It's much harder to overflow a QString by accident than a char *. (The STL is similar there, but IMHO the STL is a horrible runtime library and should be replaced by QtCore or a subset of it. :-)
The standard container library has some rather strange stuff, like operator[] on array-like containers which doesn't do bounds checking. To get bounds checking, you have to use the at() member function instead.
Furthermore, operators are assumed to be cheap to copy, so they are usually implemented as pointers. It is theoretically possible to make sure that the pointed-to container elements are live or that the iterator does not stray out of bounds, but the debug mode which does that is too slow for production use.
There is some fairly horrible stuff, like std::copy:
http://en.cppreference.com/w/cpp/algorithm/copy
You can pass a std::vector<T>::iterator (say, the result of begin()) as the output iterator, but it's your job to ensure that there's enough space. Just like strcpy, and we all know how well that worked in practice.
That being said, my recent experience *writing* C++03 code has been rather positive.