Re: [v3] PR 10975

[Paolo Carlini <pcarlini at unitus dot it>]

Nathan Myers wrote:

> > Hi Jerry. The patch itself it's safe but I'm not sure we really want
> > to apply it now, without the corresponding DR. In fact, this situation
> > happens again and again:
> >
> > 1- We are unsure about the correct interpretation of something.
> > 2- Nathan says: hey, the following is obviously ;) what we(I) wanted: ...
> For the record, I didn't have anything to do with stringstream.
... you get the point ;) ...

> As I understand it, according to either version of the standard (pre- 
> and post-DR) the current implementation is wrong.  The current standard
> says that seeks should fail if the pointers are null, but in our current
> implementation they are not (in fact) null.  So, yes, there really is a 
> defect, and there really is a bug, but that defect had been confused 
> with the bug that provoked PR 10975.  Jerry has elucidated the true 
> source of 10975, and the fix, which is happily consistent with both the 
> current standard and the (to-be-) proposed fix.  ICC8 might or might 
> not be conformant (depending upon how they default-initialize their 
> stringbuf's pointers) but may in any case be fixed similarly.
Ok, now I see: basically, from the implementation point of view, the body of
basic_stringbuf::seekoff() doesn't need to be protected from capacity() 
== 0,
because it's already able to deal with that case: seeking to pos_type(0)
succeeds, seeking to pos_type(0) automatically fails, as should be. And in
this way we are consistent with basic_filebuf. Good.

Now, one remaining doubt: what about basic_stringbuf::seekpos? Shouldn't we
remove the check on _M_string.capacity() from there too?

Paolo.