Re: [v3] char_traits error checking

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Mar 11, 2002 at 09:35:02PM -0800, Benjamin Kosnik wrote:
> 
> > > 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.  
> 
> It's unspecified what is thrown: length_error, as the other string ctors?

Something more basic, I would expect: logic_error, maybe.  Telling
a library function to dereference a null pointer is a very grave.
 
> Besides the string issue, is char_traits<char>::length(0) really 
> undefined? Or for that matter char_traits<char>::find(0, 4, 'c')?
> 
> 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.
> 
> ?

The expression *q is undefined for q == p when p is null, so 
X::length and X::find may be presumed undefined for null p.
But I wouldn't want to add checking to the traits members (nor to 
memcpy!); dumping core is sufficient diagnostic for them.  String
members are a different matter; string users are not to be presumed
as competent at traits members.
 
> 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.

Grumble.  You can't turn your back on the LWG for a second.

Nathan Myers
ncm at cantrip dot org