[v3] PR 10975

[Paolo Carlini]

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.