a067cbcdcc
When concatenating a path we reallocate the left operand's storage to make room for the new components being added. When the two operands are the same object, or the right operand is one of the components of the left operand, the reallocation invalidates the pointers that refer into the right operand's storage. The solution in this commit is to detect these aliasing cases and just do the concatenation in terms of the contained string, as that code already handles the case where the string aliases the path. The standard specifies the concatenation in terms of the native() string, so all this change does is disable the optimized implementation of concatenation for path objects which attempts to avoid re-parsing the path from the concatenated string. The potential loss of performance for this case isn't likely to be an issue, because concatenating a path with itself (or one of its existing components) probably isn't a common use case. The Filesystem TS implementation doesn't have the optimized form of concatenation and always does it in terms of the native string and reparsing the whole thing, so doesn't have this bug. A test is added to confirm that anyway (that test has some slightly different results due to different behaviour for trailing slashes and implicit "." filenames in the TS spec). libstdc++-v3/ChangeLog: PR libstdc++/120029 * src/c++17/fs_path.cc (path::operator+=(const path&)): Handle parameters that alias the path or one of its components. * testsuite/27_io/filesystem/path/concat/120029.cc: New test. * testsuite/experimental/filesystem/path/concat/120029.cc: New test. |
||
|---|---|---|
| .. | ||
| directory_entry | ||
| file_status | ||
| filesystem_error | ||
| iterators | ||
| operations | ||
| path | ||