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.
--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
