On Fri, 15 Jan 2021, 19:47 Jonathan Wakely, <jwakely....@gmail.com> wrote:
> > > On Fri, 15 Jan 2021, 16:19 Alexandre Oliva, <ol...@adacore.com> wrote: > >> On Jan 15, 2021, Jonathan Wakely <jwakely....@gmail.com> wrote: >> >> > On Thu, 14 Jan 2021, 22:22 Alexandre Oliva, <ol...@adacore.com> wrote: >> >> ... it is definitely the case that the target currently defines >> wchar_t, >> >> and it even offers wchar.h and a lot of (maybe all?) wcs* functions. >> >> This was likely not the case when the patch was first written. >> >> >> >> I'll double check whether any of the patch is still needed for current >> >> versions. >> >> With the tests I've run since yesterday, I've determined that: >> >> - the wchar-related patches for the libstdc++ testsuite, that I had >> proposed last year, are no longer needed >> >> - your two patchlets did not bring about any regressions to test >> results, not in mainline x86_64-linux-gnu native, not with the trivial >> backports to the gcc-10 tree for x-arm-vxw7r2 that was the focus of my >> immediate attention. >> >> So, I withdraw my submissions of the testsuite patches, and I encourage >> you to proceed with the two changes you proposed. >> > > Great, I'll save them in a git branch to be revisited in stage 1. > I've committed a series of 8 patches to enable partial wchar_t support even without a working <wchar.h> in libc. std::wstring and std::wstring_view should work fine now (albeit slower than if libc provides optimised wcslen etc.) Wide character I/O and charset conversions still require libc support, so are disabled when _GLIBCXX_USE_WCHAR_T is not defined. I would appreciate confirmation that this hasn't caused any problems for vxworks (understanding that vxworks does have wide character support in libc now, as discussed back in January). > > >> However, for avoidance of any doubt, I'll restate that I cannot vow for >> whether they're enough to fix the issues we'd run into back when >> wchar/wcs* were not supported in the target system, because now they >> are, so the changes do not bring any visible improvements to our results >> either. >> > > Understood, thanks for checking them though. > > >>