Subject: Re: [boost] [filesystem] fix recur_dir_itr_imp::increment(system::error_code* ec) in 1.54.0
From: Claudio Bley (claudio.bley_at_[hidden])
Date: 2013-06-11 02:17:26
At Fri, 24 May 2013 10:23:31 +0200,
Claudio Bley wrote:
> At Thu, 23 May 2013 05:10:37 -0400,
> Rob Stewart wrote:
> > On May 22, 2013, at 4:11 AM, claudio.bley_at_[hidden] (Claudio Bley) wrote:
> > > What's happening to the filesystem library? It seems there's no progress on any tickets in the bug tracker?
> > I'll speculate that Beman has been focused on the Filesystem
> > proposal, endian, etc.,
> OK, everyone's busy, I know. But some of these bugs have a long
> history and date back more than a year ago. I know next to nothing
> about Boost's development process, so bear with me. But is Beman the
> only one looking at the bugs for the filesystem library and able to
> do something about it?
> > not to mention recovering from a recent injury.
> I hope he's alright, wishing all the best!
> But, what about my original question? Can we get this fix into 1.54.0?
> I'm quoting it here for convenience:
> --- >8 ------- 8< ------- >8 ----- 8< -------- >8 ---------- 8< -----------------
> With v3, the directory_iterator at the top of the stack is invalid
> (ie. an end iterator) if an error occurs. So, you cannot dereference
> it, and you cannot use any other method (e.g. no_push) on it,
> otherwise std::abort will be called.
> Simple fix: just don't push an end iterator to m_stack.
> --- C:\Users\Claudio\src\boost.svn\boost\filesystem\operations.hpp 2012-07-24 08:43:28 +0200
> +++ boost\filesystem\operations.hpp 2013-03-25 17:21:39 +0100
> @@ -791,9 +791,11 @@
> - m_stack.push(directory_iterator(m_stack.top()->path(), *ec));
> + directory_iterator next = directory_iterator(m_stack.top()->path(), *ec);
> if (*ec)
> + else
> + m_stack.push(next);
> if (m_stack.top() != directory_iterator())
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk