[libcxx-commits] [PATCH] D91137: [5/N] [libcxx] Convert paths to/from the right narrow code page for narrow strings on windows

[Martin Storsjö via Phabricator via libcxx-commits]

mstorsjo added inline comments.


================
Comment at: libcxx/src/filesystem/operations.cpp:1675
+  ErrorHandler<size_t> err("__wide_to_char", nullptr);
+  UINT codepage = AreFileApisANSI() ? CP_ACP : CP_OEMCP;
+  BOOL used_default = FALSE;
----------------
mstorsjo wrote:
> amccarth wrote:
> > I'm not clear on what AreFileApisANSI does, nor have I found it using code search.  In what case would any APIs use the OEM code page when the user's code page is something else?
> > 
> > I'm also wondering whether CP_ACP should be CP_THREAD_ACP, which, by default, will be the user's current code page which could be different than the system code page.
> See D91133 for a testcase (which passes with MSVC STL) for this and some more - a process can switch between whether the narrow file apis take OEM CP or ACP with SetFileApisToANSI() and SetFileApisToOEM().
> 
> The MSVC STL sources don't seem to use CP_THREAD_ACP at least... however they also check for `___lc_codepage_func() == CP_UTF8`, which I guess we also should...
To follow up on the last bit regarding `___lc_codepage_func()`, contrary to `SetFileApisToOEM()` which operates on the kernel32 level, affecting how all narrow file names are interpreted, one can also do `setlocale(LC_ALL, ".utf8");`, which makes e.g. `fopen()` work with utf8 file names, but it has no effect on actual kernel32 -A suffixed file APIs.

But in any case, I guess adding the extra check for `___lc_codepage_func()`, like `___lc_codepage_func() == CP_UTF8 ? CP_UTF8 : AreFileApisANSI() ? CP_ACP : CP_OEMCP`.

After reading up on CP_THREAD_ACP, I don't think that's relevant. The main point is that if I export a narrow form of a filename from a std::filesystem::path object (or create a path object from a narrow string), I expect the string to be in the same codepage that `fopen()` or `CreateFileA()` would accept and interpreted in the same way, and as far as I'm reading about CP_THREAD_ACP, it only affects other bits, but not how kernel32 file APIs map narrow chars to wchar.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91137/new/

https://reviews.llvm.org/D91137