On 14/01/21 13:41 +0000, Jonathan Wakely wrote:
><aside>
>Is it the case that the wchar_t type is defined on this target, it's
>just that libc doesn't have support for wcslen etc?  Because we should
>probably audit all our uses of _GLIBCXX_USE_WCHAR_T and find which
>ones actually need libc support and which just need the wchar_t type
>to exist. Some things really do need the libc support, but I suspect
>many others don't.
>
>It seems wrong that we can provide full support for char16_t and
>char32_t but not wchar_t, just because the former two don't depend on
>anything being present in libc. Why can't we just implement the same
>functionality for wchar_t without using libc?
>
>In fact, if we just define std::char_traits<wchar_t> generically
>without using any libc functions (or just using them as optimisations)
>we might be able to support std::basic_string<wchar_t> and iostream
>classes with almost no work. But that's something to consider in the
>future.
></aside>

Oops, I considered it already.

This untested patch should define std::char_traits<wchar_t> so it is
available if wchar_t is defined by the front end (which I assume is
always true, is that right?), only using optimized libc routines if
available.

This would be the first step to enabling std::wstring etc for targets
with no wchar_t support in libc.