[libcxx-commits] [PATCH] D146398: [libcxx] Fix using std::wcout/wcin on Windows with streams configured in wide mode
Tom Honermann via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Thu Apr 20 15:30:19 PDT 2023
tahonermann added a comment.
> It does something somewhat reasonable at least; `fopen(); fputwc()` ... on Linux writes the wchars as plain ASCII, anything outside of the ASCII range seems to produce literal ? chars.
The `fputwc` man page claims conversion to the locale encoding; which defaults to "C" unless `setlocale()` has been called. So ASCII by default, but maybe not.
> Can you show examples on how one could experimentally try out imbuing a nondefault locale for the wcout/wcerr/wcin streams, to experimentally see how MS STL behaves in that case?
Here you go: https://godbolt.org/z/esP1535P4. Interesting, it looks like the Microsoft and libc++ implementations both call the `codecvt` members for each individual character while libstdcxx batches them. (I had to test MSVC locally; I look forward to someday being able to run MSVC generated code on godbolt.org again!)
> So with that in mind, I guess we should try to keep the current codepaths that do conversions but either avoid hitting them or keeping the original wchar form around if noconv is returned... I guess I should sit down with the MS STL implementation and see if I can trace what codepaths it ends up using for e.g. wcout.
I would expect that `noconv` will never be true when the internal and external character types differ since, at a minimum, a (potentially narrowing) copy has to be performed.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D146398/new/
https://reviews.llvm.org/D146398
More information about the libcxx-commits
mailing list