AIX have 2 byte wchar in 32 bit mode and 4 byte wchar in 64 bit mode.
This patch add more missing short wchar handling under the existing _LIBCPP_SHORT_WCHAR macro.
Details
Diff Detail
Event Timeline
Why did you have to add a specialization based on size? Could you provide a test case or two to help explain. My first thought is the _LIBCPP_SHORT_WCHAR macro should be good enough since aix & z/OS only support one wchar_t size per 32/64 bit mode.
With -fshort-wchar, you could have a short wchar in 64 bit mode. So this implementation still gives you the correct result if that's used.
It looks like there are few test cases failing in Windows. Was that investigated to see if it is related to this patch?
Relay some offline discussion: t -fshort-wchar is something that most of libc libraries doesn’t support. i.e. wchar functions won’t return a sensible result when -fshort-wchar is enabled. So there is no point to try to make it work with libc++. So choosing to use existing macro _LIBCPP_SHORT_WCHAR to handle the wchar size differences here.
As expected, this changes the behavior of windows platform for the do_length and do_max_length of __codecvt_utf8<wchar_t>.
But I think the changes are actually desired. Could anyone working on Windows platform confirm that?
If we could agree on that, then I could work on updating the test case.
Can you rebase onto main to trigger CI? This LGTM but I'd like @mstorsjo to peek at this since that setting is used on Windows too.
Yes, Windows has got 2 byte wchar_t - so if I read this correctly, libc++ has got an existing define for _LIBCPP_SHORT_WCHAR, but it was incomplete/inconsistent, and this fixes up things to work more correctly for that case? That's certainly good.
In practice, which cases didn't work as they should in that configuration before? I haven't noticed that aspect anywhere in the libc++ tests on Windows (although it could be hidden by some XFAIL: LIBCXX-WINDOWS-FIXME, but that would show up as XPASS in that case too).
If we could agree on that, then I could work on updating the test case.
I don't on a quick glance see what the practical effect of the test updates is, but if it still passes in the Windows CI configurations I guess it should be fine.
@mstorsjo I modified the test case so that it would produce the correct result for 2 byte wchar. Without those test case modification, windows CI would fail.
Those test case weren't testing the correct thing for 2 byte wchar and thus previous behavior that produced a result that's intended for 4 byte wchar on Windows verified "clean".