Re: [v3] char_traits error checking

[Benjamin Kosnik <bkoz at redhat dot com>]

> > This cores, at least on x86/linux. I'd think this is something that
> > should be avoided, if possible.
> 
> It's undefined, so we're allowed to do anything we like, including dump
> core.  I'd much, much rather throw, however, than treat it as an empty 
> string.  We don't do users any favors by concealing their dependence on 
> undefined behavior.  

Ah ha! You are correct.

21.3.1 - basic_string constructors
basic_string(const charT* s, const Allocator& a = Allocator());
-9- Requires:  s shall not be a null pointer.

It's unspecified what is thrown: length_error, as the other string ctors?

Besides the string issue, is char_traits<char>::length(0) really 
undefined? Or for that matter char_traits<char>::find(0, 4, 'c')?

21.1.1 - Character traits requirements

X::length(p)size_t yields: the smallest i such that X::eq(p[i],charT()) 
is true. linear 

X::find(p,n,c) const X:: char_type* yields: the smallest 
q in [p,p+n) such that X::eq(*q,c) is true, zero otherwise.

?

I agree, the compare semantics are unclear for a null string. The other 
two member functions, however, seem to indicate that the NULL case should 
be handled.

-benjamin