[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e06d3f5dd7d0c6b4a20fe813e6ee5addd097f560 commit r11-8031-ge06d3f5dd7d0c6b4a20fe813e6ee5addd097f560 Author: Jonathan Wakely Date: Wed Apr 7 16:05:42 2021 +0100 libstdc++: Fix filesystem::path construction from COW string [PR 99805] Calling the non-const data() member on a COW string makes it "leaked", possibly resulting in reallocating the string to ensure a unique owner. The path::_M_split_cmpts() member parses its _M_pathname string using string_view objects and then calls _M_pathname.data() to find the offset of each string_view from the start of the string. However because _M_pathname is non-const that will cause a COW string to reallocate if it happens to be shared with another string object. This results in the offsets calculated for each component being wrong (i.e. undefined) because the string views no longer refer to substrings of the _M_pathname member. The fix is to use the parse.offset(c) member which gets the offset safely. The bug only happens for the path(string_type&&) constructor and only for COW strings. When constructed from an lvalue string the string's contents are copied rather than just incrementing the refcount, so there's no reallocation when calling the non-const data() member. The testsuite changes check the lvalue case anyway, because we should probably change the deep copying to just be a refcount increment (by adding a path(const string_type&) constructor or an overload for __effective_range(const string_type&), for COW strings only). libstdc++-v3/ChangeLog: PR libstdc++/99805 * src/c++17/fs_path.cc (path::_M_split_cmpts): Do not call non-const member on _M_pathname, to avoid copy-on-write. * testsuite/27_io/filesystem/path/decompose/parent_path.cc: Check construction from strings that might be shared.
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 --- Comment #5 from Jonathan Wakely --- It would have worked if it used std::as_const(_M_pathname).data() or _M_pathname.c_str() instead of _M_pathname.data(). It's only the non-const data() added in C++17 which reallocates (since r261642 anyway).
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #4 from Jonathan Wakely ---
Wow, this is tricksy.
The bug happens when parsing the string into a path. The path is split into
components and the offset of each component from the beginning of the string is
stored, so that parent_path() can efficiently erase the part of the native()
string that refers to the last component. The offset is calculated like this:
for (auto& c : buf)
{
auto pos = c.str.data() - _M_pathname.data();
::new(output++) _Cmpt(c.str, c.type, pos);
++_M_cmpts._M_impl->_M_size;
}
The bug is that for the COW std::string _M_pathname.data() causes the string to
be reallocated, and so changes the address at which the string is stored. So
the string_view c.str no longer refers to the same data as _M_pathname. We get
a bogus offset for the components, and when we try to remove the last component
to get the parent_path(), we don't remove anything from the string.
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 Jonathan Wakely changed: What|Removed |Added Known to fail||10.2.0, 11.0, 9.3.0 Target Milestone|--- |9.4 Summary|filesystem::path::parent_pa |[9/10/11 Regression] |th got a wrong path |filesystem::path::parent_pa ||th got a wrong path Known to work||8.4.1
