On 3/5/16 1:45 AM, John Maddock wrote:

On 05/03/2016 06:33, Robert Ramey wrote:

...

I've (finally!) got the latest version of the serialization library to pass all the tests on develop. I would like to merge develop to master. May I do this?

I still see a few issues:

* The program iterator_test.cpp aborts when it tries to increment an out-of-range vector iterator with msvc (14 and 12).

I see this on the test matrix, but I haven't been able to reproduce it locally.

* Running the serialization tests under valgrind on Linux flags up a lot of failures (many of which may all be the same issue) - you can reproduce with

bjam toolsetname testing.launcher="valgrind --error-exitcode=1"

Hmmm - there are a number of tests which trap in sanitizers and in valgrind. These are artifacts of the tests and not the library. I think most of these are dangling pointers which result from not deleting dematerialized data structures via pointers. If I had nothing else to do, I might go back and fix these tests - but it's a lot bigger job than meets the eye and I've got other stuff to do.

* There's at least one multiprecision test which fails with the new version (test_cpp_int_deserial.cpp) with vc12 and earlier, but not vc14 strangely. It dies with an archive exception complaining that the archive is invalid with some VC compiler versions but not others.

The changes in this round are of the following a) miscellaneous trac items fixed. b) re-enabled codecvt facet which at some point got disabled. c) modified code to use the standard library implementation of codecvt if it's available and to use the local boost codecvt implementation otherwise. This likely explains the difference in results between msvc versions. d) Enhancement to the test multi-byte characters. This generated errors which have always been there by have never before been detected. Among these places is i) codecvt in some versions of the standard library ii) codevt in some versions of msvc iii) visibility attribute in boost codecvt facet So, I believe that even though we are trapping more bugs, this is a strict improvement to the previous version. Robert Ramey

On 3/5/16 10:51 AM, John Maddock wrote:

...

...

I still see a few issues:

* The program iterator_test.cpp aborts when it tries to increment an out-of-range vector iterator with msvc (14 and 12).

I see this on the test matrix, but I haven't been able to reproduce it locally.

That's weird, it's easily reproducible for me with VC14 x86 debug mode.

LOL - It might be for me as well if I had MSVC installed.

In the test case you have:

std::vector<wchar_t> la2; { typedef boost::archive::iterators::wchar_from_mb<std::vector<char>::const_iterator> translator; std::copy( translator(a.begin()), translator(a.end()), // bug here std::back_inserter(la2) );

The call to translator(a.end()) leads to wchar_from_mb.hpp:137:

typename boost::iterators::iterator_reference<Base>::type c = *(this->base_reference()++);

Where an attempt is made to dereference and increment the result of the previous call to end().

OK - this is very helpful.

The issue was that constructing an input archive from a std::ifstream dies if there's a peek() on the stream prior to the archive constructor. I suspect this is due to the calls to imbue() in the archive constructor invalidating the stream buffer and the fstream then gets it's internals in a twist.

Also very helpful. Thanks for this. Thinking about this though. In the tests the sequence is construct stream construct archive(stream) // call imbue here But the stream buffer has just been constructed! How could imbue be called at any earlier time! I'll look into this again though. Robert Ramey

HTH, John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost