Workaround for opening file streams using wide string paths on old versions of MinGW

[rikyoz]

On old MinGW versions, opening file streams using wide string paths is not supported. This basically makes it impossible to use ghc::filesystem's streams for opening files with a Unicode character in the path since, by default, the narrow path string (UTF-8 encoded) gets interpreted by Windows using the system codepage (unless you force the program to use UTF-8 via a manifest file).

Example:

#include <iostream>

#include <Windows.h>

#include "ghc/filesystem.hpp"

namespace fs = ghc::filesystem;

constexpr auto path_str = L"αρχείο.txt";

auto main() -> int {
    std::cout << "System codepage: " << GetACP() << std::endl;

    const auto path = fs::path{ path_str };
    {
        fs::ofstream ofs{ path, std::ios::binary };
        ofs << "hello world!" << std::endl;
    }
    std::cout << "File exists: " << std::boolalpha << fs::exists( path ) << std::endl;
}

Output:

However, old versions of MinGW might support the _wsopen_s function, a Microsoft extension that allows opening a file using a wide C string path. This, together with an internal function of libstdc++ (__gnu_cxx::stdio_filebuf), can be used to implement a workaround.

The workaround is used only if libstdc++ doesn't natively support opening file streams using wide string paths (#172), which is the preferred way on recent versions of MinGW.

Output with the workaround:

I tested it with both MinGW 7 and 8, which do not support GHC_HAS_FSTREAM_OPEN_WITH_WCHAR, but support _wsopen_s.

As a side note, I had to modify the CMake files so that the -Wa,-mbig-obj parameter is passed to all the test targets; otherwise, MinGW fails while linking the executables.

I hope everything is ok!

[gulrak]

Sorry for taking an unbelievable time to actually react, I had taken some time of of this project sadly. When the PR was made I gave it a look, but it is quite a bit of code that I couldn't test and currently have no CI pipeline to verify, so I can't easily support it, once it is in. I'm still undecided if I want to merge this sadly, but I at least wanted to comment, and thank for the effort. I will give it another look, but I want to get a bunch of fixes out and I will probably defer that to the release after that, if I find a way to verify and CI-test that.

[rikyoz]

Sorry for taking an unbelievable time to actually react, I had taken some time of of this project sadly

No worries about it, I figured it was something along those lines.

When the PR was made I gave it a look, but it is quite a bit of code that I couldn't test and currently have no CI pipeline to verify, so I can't easily support it, once it is in. I'm still undecided if I want to merge this sadly, but I at least wanted to comment, and thank for the effort. I will give it another look, but I want to get a bunch of fixes out and I will probably defer that to the release after that, if I find a way to verify and CI-test that.

I completely understand the concern about merging code that can't be verified by CI. The workaround is only enabled on older MinGW/libstdc++ versions where wide-path stream support is missing, so it shouldn't affect newer toolchains at all, but I agree that having automated coverage would make it much more comfortable to maintain.

That said, this PR only fixes an issue affecting older versions of MinGW, so I completely understand if you decide the additional maintenance burden isn't worth it.