I've reproduced the same problem and confirmed the fix with boost 1.66 too. Unfortunately I was unable to get the current state of Boost master to compile in order to run the test suite there. Hopefully travis/appveyor will tell me if I've broken anything.

The AppVeyor test failure appears to be:

libs\filesystem\test\operations_test.cpp(1394): test 'fs::exists(link)' failed in function 'void __cdecl `anonymous-namespace'::remove_symlink_tests(void)'

The remove_symlink_tests test doesn't even seem to use directory_iterator, so it looks like this failure may not be related to my patch.

Is there anything else that I need to do? Is my explanation not clear?

This fixes the second issue of #53, fixed by aa2a58a. But, the first issue in #53, fixed by 1303b3e, still seems outstanding. I will look at rebasing #53.

This change might be the cause of a new problem.
Consider the following code snippet :
`#include <boost/filesystem.hpp>
#include

int main()
{
const std::string path{"/tmp"};

boost::filesystem::directory_iterator iter(path);
while (iter != boost::filesystem::directory_iterator()) {
    ++iter;
}
return 0;

}`

this now gives rise to complains when this is ran with valgrind :
`
0x0
1
UninitCondition
Conditional jump or move depends on uninitialised value(s)


0x4E46531
/home/ldco/boost/lib/libboost_filesystem.so.1.69.0
boost::filesystem::detail::directory_iterator_increment(boost::filesystem::directory_iterator&, boost::system::error_code*)


0x4E4804A
/home/ldco/boost/lib/libboost_filesystem.so.1.69.0
boost::filesystem::detail::directory_iterator_construct(boost::filesystem::directory_iterator&, boost::filesystem::path const&, boost::system::error_code*)


0x405D12
/home/ldco/Projects/TryOuts/FileSystem0/Deliv/Debug/FileSystem0-Paths
boost::filesystem::directory_iterator::directory_iterator(boost::filesystem::path const&)

gcc : gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
valgrind : valgrind-3.13.0

===> so conditional jump based on uninitialized values ==> that sounds like undefined behaviour ?

Should be fixed in bbe9d17, thanks.

This change might be the cause of a new problem.
Consider the following code snippet :
`#include <boost/filesystem.hpp>
#include

int main()
{
const std::string path{"/tmp"};

boost::filesystem::directory_iterator iter(path);
while (iter != boost::filesystem::directory_iterator()) {
    ++iter;
}
return 0;

}`

That code runs fine for me under valgrind with boost 1.63 + my patch (which is what I did most of my testing on) and boost 1.66 + my patch (which is what I'm currently shipping.) I haven't upgraded to anything newer yet.

I suspect that your problem is not related to this pull request.

Mike.

the problem I mentioned occurs in boost 1.69, and was still working ok in boost 1.68, the fact I ended up in this ticket is due to the release notes : Fixed undefined behavior in boost::filesystem::directory_iterator implementation. (PR#77)
That's how I made the link, I will past my boost install with the fix mentioned above, and report back.

Yes, it is not related to this PR. The problem was present in code since ba4aaf3, which is the initial release of Boost.Filesystem v3. It did not reproduce on Linux before Boost 1.69 (more precisely, until 48b8d75) because a different code branch was used on Linux. The problem could reproduce on other platforms before that revision.

I have patched my boost environment with the mentioned fix above, and can confirm that valgrind is happy again :-)