Opened 10 years ago
Last modified 7 years ago
#7538 new Bugs
boost::spirit::istream_iterator does not handle incrememt correctly at the end
Reported by: | Owned by: | Joel de Guzman | |
---|---|---|---|
Milestone: | To Be Determined | Component: | spirit |
Version: | Boost 1.52.0 | Severity: | Showstopper |
Keywords: | spirit, istream_iterator, multi_pass | Cc: |
Description
boost::spirit::istream_iterator
(or its super class multi_pass
)does not handle incrememt correctly at the end position.
One more end char will be yielded which is incorrect:
#include <sstream> #include <boost/spirit/include/support_istream_iterator.hpp> #include <boost/test/minimal.hpp> int test_main(int, char*[]) { std::istringstream in("12"); boost::spirit::istream_iterator it(in), end; BOOST_CHECK(*it++ == '1'); BOOST_CHECK(*it++ == '2'); // it should be end now, however it failed BOOST_CHECK(it == end); // !failed here // and yield the last char once more BOOST_CHECK(*it != '2'); // !failed here // only after another dereference will it really equal to end BOOST_CHECK(it == end); return 0; }
The output is:
test.cpp(14): test it == end failed in function: 'int test_main(int, char **)' test.cpp(16): test *it != '2' failed in function: 'int test_main(int, char **)' **** 2 errors detected
#6750 may be a duplicated issue.
Reproducable under:
- Apple clang version 4.1 (tags/Apple/clang-421.11.65) (based on LLVM 3.1svn)
- Target: x86_64-apple-darwin12.2.0
- With C++ 11 turn on: "-std=c++11 -stdlib=libc++"
- Boost 1.52 and Boost Trunk rev.81030
Change History (2)
comment:1 by , 7 years ago
comment:2 by , 7 years ago
I forgot to mention that I was testing against the develop branch of spirit, everything else in boost was the current master branch. The last commit was for spirit was 850c71a3d78665359911a15911cf263763087eff
.
Note:
See TracTickets
for help on using tickets.
I would mark this as rejected (or similar). I tried this with:
and only the
BOOST_CHECK(*it != '2');
check failed. However, thats undefined iterator behavior since the iterator currnetly equals the end. So I'm not sure what caused this, but it doesn't show up on newer clang-Apple builds.