From: David Abrahams (dave_at_[hidden])
Date: 2006-01-30 21:20:17
"Eric Niebler" <eric_at_[hidden]> writes:
> David Abrahams wrote:
>> If you're going to go through code
>> and replace fixed-sized char arrays on the stack with something more
>> reliable, it makes no sense at all to go halfway and use something
>> that is still going to give you problems when your input data is
>> larger than you might have anticipated (or whatever).
> I'm going to play devil's advocate here and disagree for the sake of
> discussion. You're ignoring failure mode. A string truncation bug is, in
> all likelyhood, less severe than a buffer overrun.
Maybe. Probably. So what?
If you're going to change the code anyway, why not change it to
something that avoids both, reliably?
> If, for instance, there were a large monopolistic corporation trying
> to eliminate remote exploits from their ENORMOUS codebase, a switch
> to something like fixed_string might be significantly cheaper than
> reengineering their code to work with a growable string class.
Seems to me that if you can write
you can just as easily write
> A different approach to achieve the same ends might be to define
> overloads of the C string APIs that worked with std::string,
Gee that smells like a familiar idea ;-)
> so the migration of legacy code can actually eliminate bugs instead
> of making them less severe. Has this approach been considered?
I think that's my point, Eric :)
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk