[libcxx-commits] [PATCH] D124555: [libcxx][AIX][z/OS] basic_ios<wchar_t> cannot store fill character WCHAR_MAX

Chris Bowler via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Wed Apr 27 13:59:13 PDT 2022

cebowleratibm created this revision.
cebowleratibm added reviewers: xingxue, SeanP, hubert.reinterpretcast, daltenty.
Herald added a project: All.
cebowleratibm requested review of this revision.
Herald added a project: libc++.
Herald added a subscriber: libcxx-commits.
Herald added a reviewer: libc++.

On AIX and zOS in 64-bit mode, wchar_t is 4 bytes unsigned and wint_t is also 4 bytes.  libcxx std::basic_ios uses WEOF to indicate that the fill value is uninitialized, which cannot be distinguished from WCHAR_MAX by std::char_traits<wchar_t>::eq_int_type.

The constraints of the C++ standard impose:

  -Cannot map any wchar_t value to WEOF.
  -All wchar_t values must map uniquely.
  -wint_t and wchar_t have the same width on AIX in 64-bit mode.

The library is implemented correctly with respect to the C++ standard, however, an implementation cannot be compliant where wchar_t is unsigned and the same size as wint_t, consequently I've added a __fill_set_ member to indicate whether or not the fill character has been initialized.

I plan to have IBM follow up with the C++ standard to have the contradiction dealt with.

The change is enabled in both 32 and 64 bit on AIX and z/OS for compatibility with the current IBM system provided libc++ on the targets.  Unfortunately this member could have been added more selectively, however, in interest of compatibility I need to propose the patch as-is.

  rG LLVM Github Monorepo



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D124555.425599.patch
Type: text/x-patch
Size: 3614 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20220427/63c09d37/attachment.bin>

More information about the libcxx-commits mailing list