Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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.