https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Summary|wstring-constructor of |[9/10/11 Regression]
|std::filesystem::path |wstring-constructor of
|throws for non-ASCII |std::filesystem::path
|characters |throws for non-ASCII
| |characters
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In libstdc++ filesystem::path uses std::codecvt<wchar_t, char, mbstate_t> to
convert from wide character strings in the native wide encoding format (which
is set by GCC's -fwide-exec-charset option) to the native encoding for
pathnames.
The native encoding for pathnames should be UTF-8, but because we use codecvt,
which uses wcsnrtombs, we're actually converting to the narrow encoding of the
current C locale (which is ASCII by default as Carlos said).
So I think libstdc++ needs to use a different conversion from the native wide
encoding to UTF-8 (to be independent of the current locale's narrow encoding).
This would have changed with r272385 (and r272389 on the gcc-9 branch) which
was fixing PR libstdc++/90281.
