On 15 January 2011 12:33, Tom Browder wrote: > > Here's the situation: > > open source library A (http://brlcad.org) with many kloc of C code by > many people over decades > - possible lots of hidden null ptr string bugs remaining (one found > just recently) > > open source library A++ wrapping lib A > > user of A++ gets stuck and finds one of the null char* bugs as it is > used to construct a C++ string > > user of A++ can't fix A++ > > Now consider my original suggestion with this modification: > > consider it a built-in try {} catch {} block and trap the exception > and return an empty string as well as report the problem to stderr > > The compiler option might be something like: > > "--auto-catch-c++-null-string-exception" > > Now the user may be able to carry on and he can also report the bug. It can't be a compile-time option, it would create ODR violations if some files are compiled with that option and others are not. So it would have to be an option used when building and installing GCC. Rather than rebuilding GCC with that option, it would be quicker and easier to fix the open-source library yourself, or if you really think it's a good idea to ignore that error, just patch your local GCC headers in order to be able to carry on. You're asking for us (the libstdc++ maintainers) to maintain an additional configuration option which increases the burden of testing and maintaining the library, for questionable benefit. Yes, there's a use case, but is it really significant? Adding that option would mean changes to std::string need to be evaluated in terms of impact on the default configuration, and --enable-fully-dynamic-string, and your proposed option, and all the combinations of those - that would be four combinations to consider.
