Re: [v3] PR 10975

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

On Tue, Jan 06, 2004 at 04:42:16PM +0100, Paolo Carlini wrote:
> 
> Now, one remaining doubt: what about basic_stringbuf::seekpos? Shouldn't
> we remove the check on _M_string.capacity() from there too?

seekpos behavior certainly should match seekoff.  Anyhow I don't find
any remarks in the seekpos description indicating it should fail.

Having read through the whole section again, though, it appears
that whoever wrote it really did mean for stringstream to have a 
"not yet opened" mode -- indeed, three different not-entirely-open
modes  The description of the default constructor says it calls 
"basic_streambuf()", i.e. a specific base-class constructor that, 
initializes all the pointers to zero.  The description of the other 
constructor describes "initializing" input and/or output sequences; 
if not "initialized", they would be left as set by the base-class 
ctor, i.e. null.  

In that context, the bit in 27.7.1.3p11 about "gptr() or pptr() is
a null pointer" would have to refer to that "uninitialized" state,
because nothing else could make them null.

So, Paolo's reservations are well-founded.  I apologize for adding
to the confusion, and to Jerry's workload.  This means that Jerry's 
investigation may have revealed may be that the stringbuf ctor is 
in fact over-aggressive in initializing the various pointers, and 
that anybody who wants seekoff on an empty stringbuf to succeed must 
initialize it from an empty string.

All this is needlessly complicated, of course.  There's no practical
reason not to keep all the pointers initialized and consistent all 
the time.  Sigh.

Nathan Myers
ncm-nospam@cantrip.org