[v3] Fix stringbuf handling of NUL characters

[Nathan Myers]

On Mon, Jul 16, 2001 at 01:01:19PM -0400, Phil Edwards wrote:
> On Sat, Jul 14, 2001 at 02:49:39AM +0200, Carlo Wood wrote:
> > On Fri, Jul 13, 2001 at 04:24:23PM -0400, Phil Edwards wrote:
> > > But that's not c_str()'s fault.  Both c_str() and data() simply return a
> > > pointer to the character string.  A second NUL character (which will never
> > > be seen) won't make any difference.
> > > 
> > > It's just occurred to me that we may be talking about different things
> > > anyhow.  :-)
> > 
> > It irrelevant for the patch anyway, you should use data() if only because
> > it is faster.
> 
> Yep, I believe I said exactly that a few days ago.  :-)
> 
> As an aside, I looked through the stringbuf/stringstream code for other
> instances of c_str(), and there are none.  In fact, we use surprisingly
> few member functions of basic_string, which I consider to be a good thing.

One of the original design goals for string (later basic_string<>) was
that it would treat NUL specially only where it was asked to operate
on a C string.  When it became basic_string<>, the goal was that it
would mention char_traits<>::eos() only where the interface demanded 
it (i.e. where it took or returned just a raw a charT*, data() excepted).
That way if you didn't use such a member it would never be instantiated,
and your code wouldn't even need to have char_traits<T>::eos() defined, 
for some T.

Then I was out of the room for a few minutes and they resolved that 
s.operator[] should return eos() if its argument was s.size(), and
all that care went out the window.  

Before, we could just plug in a NUL if anybody actually called c_str(); 
now, we have to keep it plugged at all times.  

Bah.

Nathan Myers
ncm at cantrip dot org