[Boost-bugs] [Boost C++ Libraries] #13217: remove_all(const path& p, system::error_code& ec) is not supposed to throw filesystem_error, but still can

Subject: [Boost-bugs] [Boost C++ Libraries] #13217: remove_all(const path& p, system::error_code& ec) is not supposed to throw filesystem_error, but still can
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2017-09-19 20:17:47


#13217: remove_all(const path& p, system::error_code& ec) is not supposed to throw
filesystem_error, but still can
---------------------------------------+---------------------
 Reporter: Brad Spencer <bspencer@…> | Owner: (none)
     Type: Bugs | Status: new
Milestone: To Be Determined | Component: None
  Version: Boost 1.64.0 | Severity: Problem
 Keywords: |
---------------------------------------+---------------------
 I will be submitting a github pull request in association with this
 ticket.

 According to the documentation, uintmax_t remove_all(const path& p,
 system::error_code& ec) is not supposed to throw filesystem_error.
 However,
 when the directory_iterator used in the loop inside the implementation
 helper
 function remove_all_aux() is incremented, it's not done in a way that
 considers the ec argument. So, when incrementing the iterator fails, the
 operator++() on the directory_iterator throws, which leads to remove_all()
 incorrectly throwing.

 To fix this, it seems that one can take the same approach as the recent
 changes for Fix #7307 (commit 4e4374336c640c2717f6a1b168406e11bdf7d6f1)
 and replace the ++itr call in the loop with an explicit call to either
 directory_iterator::increment(system::error_code& ec) whenever an ec
 argument
 is in effect. This should prevent remove_all() from throwing in such cases
 and
 thus allow it to conform to its interface specification.

 BTW I also found these possibly related tickets in Trac:
 * #10380
 * #12640

-- 
Ticket URL: <https://svn.boost.org/trac10/boost/ticket/13217>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-09-19 20:23:42 UTC