Make tests less istreambuf_iterator implementation dependent

François Dumont frs.dumont@gmail.com
Mon Oct 2 05:43:00 GMT 2017


On 28/09/2017 23:56, Jonathan Wakely wrote:
> On 28/09/17 21:59 +0200, François Dumont wrote:
>>
>> The current istreambuf_iterator implementation capture the current 
>> streambuf state each time it is tested for eof or evaluated. This is 
>> why I considered those tests as fragile.
>
> Yes, and I think that's non-conforming.
>

Good, then we have something to fix.

> As I said in the other thread, I'd really like to see references to
> the standard used to justify any changes to our istreambuf_iterator 

I think _M_c has been introduced to cover this paragraph of the Standard:

24.6.3.1

"1. Class istreambuf_iterator<charT,traits>::proxy is for exposition 
only. An implementation is permit-
ted to provide equivalent functionality without providing a class with 
this name. Class istreambuf_-
iterator<charT, traits>::proxy provides a temporary placeholder as the 
return value of the post-
increment operator (operator++). It keeps the character pointed to by 
the previous value of the iterator for
some possible future access to get the character."

This is why it is being set in operator++(int):

     istreambuf_iterator __old = *this;
     __old._M_c = _M_sbuf->sbumpc();

It is also the reason why libstdc++ fails:
http://llvm.org/svn/llvm-project/libcxx/trunk/test/std/iterators/stream.iterators/istreambuf.iterator/istreambuf.iterator.cons/proxy.pass.cpp 


It looks like this test is simply not Standard conformant.

I guess at some point _M_c started to be used also to cache the 
streambuf::sgetc resulting in current situation.

In attached patch I limit usage of _M_c to cover 24.6.3.1.1 point and so 
made additional changes to 2.cc test case to demonstrate it.

François

-------------- next part --------------
A non-text attachment was scrubbed...
Name: istreambuf_iterator.patch
Type: text/x-patch
Size: 5232 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20171002/5a0dd5d2/attachment.bin>


More information about the Libstdc++ mailing list