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. 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. A different approach to achieve the same ends might be to define overloads of the C string APIs that worked with std::string, so the migration of legacy code can actually eliminate bugs instead of making them less severe. Has this approach been considered? -- Eric Niebler Boost Consulting www.boost-consulting.com