466. basic_string ctor should prevent null pointer error

Section: 27.4.3.2 [string.require] Status: NAD Submitter: Daniel Frey Opened: 2004-06-10 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [string.require].

View all issues with NAD status.

Discussion:

Today, my colleagues and me wasted a lot of time. After some time, I found the problem. It could be reduced to the following short example: 

  #include <string>
  int main() { std::string( 0 ); }

The problem is that the tested compilers (GCC 2.95.2, GCC 3.3.1 and Comeau online) compile the above without errors or warnings! The programs (at least for the GCC) resulted in a SEGV.

I know that the standard explicitly states that the ctor of string requires a char* which is not zero. STLs could easily detect the above case with a private ctor for basic_string which takes a single 'int' argument. This would catch the above code at compile time and would not ambiguate any other legal ctors.

[Redmond: No great enthusiasm for doing this. If we do, however, we want to do it for all places that take charT* pointers, not just the single-argument constructor. The other question is whether we want to catch this at compile time (in which case we catch the error of a literal 0, but not an expression whose value is a null pointer), at run time, or both. Recommend NAD. Relegate this functionality to debugging implementations.]

[ Post Summit: Alisdair requests this be re-opened as several new language facilities are designed to solve exactly this kind of problem. ]

[ Batavia (2009-05): ]

We are unable to achieve consensus on an approach to a resolution. There is some sentiment for treating this as a QOI matter. It is also possible that when string is brought into the concepts world, this issue might be addressed in that context.

[ 2009-07 Frankfurt ]

We considered three options:

The consensus was NAD.

Proposed resolution:

Add to the synopsis in 27.4.3 [basic.string] 

basic_string( nullptr_t ) = delete;