[libcxx-commits] [PATCH] D42225: libcxx: Provide overloads for basic_filebuf::open() et al that take wchar_t* filenames on Windows.

Martin Storsjö via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Fri Sep 24 07:18:04 PDT 2021


mstorsjo added a comment.

In D42225#3020688 <https://reviews.llvm.org/D42225#3020688>, @CaseyCarter wrote:

> In D42225#2963216 <https://reviews.llvm.org/D42225#2963216>, @ldionne wrote:
>
>> In D42225#2963190 <https://reviews.llvm.org/D42225#2963190>, @mstorsjo wrote:
>>
>>> In D42225#2962348 <https://reviews.llvm.org/D42225#2962348>, @ldionne wrote:
>>>
>>>> @pcc @mstorsjo Are we aware of anyone using these extensions?
>>>>
>>>> I would like to suggest that we either remove this extension if it's not useful, or make it unconditional (not only on Windows) if we really think it's that useful (but I'd like that to come with at least a paper proposing to add them to the standard). Carrying around an extension that's only enabled on one platform (and not the most widely used platform for libc++ at that) is kind of awkward.
>>>
>>> This extension is fairly essential - without it, you can't interact with files that have names outside of the 8 bit charset on Windows (and exactly what the 8 bit charset is, can vary from system to system). I can't point to a specific user of it, but I'd expect there to be numerous out there.
>>>
>>> Making it universally available sounds like a sensible strategy forward - although I don't think I have the bandwidth to take on making it a standards proposal. Maybe someone from Microsoft (who invented this extension) can collaborate on it?
>>
>> @CaseyCarter Any appetite for that?
>
> This isn't an extension for us. The Standard mandates overloads of `basic_filebuf::open`, `basic_ifstream::open`, `basic_ofstream::open`, and `basic_fstream::open`, as well as constructors for `basic_ifstream`, `basic_ofstream`, and `basic_fstream` that take `const filesystem::path::value_type*` which are "only be [sic] provided on systems where `filesystem::path::value_type` is not `char`." ([fstream.syn]/3) Unsurprisingly, `filesystem::path::value_type` for us is `wchar_t`. If you're supporting our mess of narrow character encodings, you may want to consider `wchar_t` for `filesystem::path` on Win32 as well. If you are only supporting UTF-8, I suppose you could instead transcode filenames to UTF-16 and use _wfopen?

We also use `wchar_t` for `filesystem::path::value_type` on Windows, essentially following the MS STL when it comes to those details. I think also libstdc++ might have added these `wchar_t` overloads these days.


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D42225



More information about the libcxx-commits mailing list