This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
basic_string
ctor should prevent null pointer errorSection: 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 proposed resolution.
- NAD
- Interpret a null pointer as the empty string.
The consensus was NAD.
Proposed resolution:
Add to the synopsis in 27.4.3 [basic.string]
basic_string( nullptr_t ) = delete;