Re: [boost] [Review] Fixed Strings review period extended

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

    strcpy(fixed_string, some_source_string);

you can just as easily write

    strcpy(growable_string, some_source_string);

instead.

> 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