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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
