fstream.hpp facilities not usable for paths containing characters outside of the current Windows ("ANSI") code page on GCC (mingw/mingw-w64)

[sam@…]

GCC's libstdc++ does not follow MS VC++'s lead in extending std::fstream and std::filebuf to take paths made up of wchar_t strings.

boost::filesystem::filebuf and {i,o,}fstream rely on this functionality. In its absence, they fall back to converting the path's wchar_t representation into a char string in the Windows ("ANSI") code page of the current system locale (actually, they incorrectly use the current thread codepage, see #5592).

The fstream facilities are therefore unusable with GCC when you build a Windows program that manipulates paths containing characters that are not representable in the current Windows code page.

When compiled with the GCC from mingw-w64, the attached test will fail to create a file. Examination with Process Monitor reveals that the program tries to create a file with the name of "umbre??a", because the ☂ character is not representable in any Windows code page.

GCC provides a gnu_cxx::stdio_filebuf, which may be constructed from a FILE* or file descriptor; this could be used in concert with MSVCRT's _wfopen or _wopen functions, by boost::filesystem::{i,o,}fstream to provide the missing functionality.

[sam@…]

Test case

[anonymous]

A patch would be much appreciated!

Thanks for creating the issue,

--Beman

[sam@…]

Having looked into this further, it seems stdio_filebuf does not provide an open function that takes a FILE* or file descriptor. This makes it rather difficult to implement b::f::filebuf::open on top of a stdio_filebuf. :(

[Eric Niebler]

reassigned to Beman

[Dominik Schmidt <domme@…>]

Does this help maybe htt*:sourceforge.net/p/mingw-w64/mailman/message/29714455/ ?

[fiesh@…]

It would be great if the documentation could be upgraded to clarify this, at least as the bug remains. tut5.cpp for example does not work correctly when using mingw. It took us a lot of time to figure out that this was the reason for the issues in our codebase. I guess this makes boost::filesystem not usable under mingw?

[anonymous]

The same has happened to us. :-( Is there any chance that tut5.cpp will be working with mingw in the near future? It should be mentioned in the documentation that mingw is not correctly supported right now!

[anonymous]

There is a GPL library that has solved the problem: ​https://www.guelkerdev.de/projects/pathie. Would it be possible to use their trick (make use of gnu_cxx::stdio_filebuf extension) or otherwise mark Boost and/or Boost Filesystem as not really supporting MinGW?! Please! Otherwise many MinGW programmers could believe (like me) that Boost Filesystem solves their file opening problem which it doesn't!!!