[libcxx-commits] [PATCH] D124555: [libcxx][AIX][z/OS] basic_ios<wchar_t> cannot store fill character WCHAR_MAX
Hubert Tong via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Thu Jun 9 15:03:42 PDT 2022
hubert.reinterpretcast added a comment.
In D124555#3566746 <https://reviews.llvm.org/D124555#3566746>, @ldionne wrote:
> template <class _Traits>
> struct _OptionalFill {
> _OptionalFill() : __set_(false) { }
> _OptionalFill& operator=(typename _Traits::int_type __x) { __set_ = true; __fill_ = __x; return *this; }
> bool __is_set() const { return __set_; }
> typename _Traits::int_type __fill() const { return __fill_; }
>
> private:
> typename _Traits::int_type __fill_;
> bool __set_;
> };
>
> Thoughts?
>From the AIX and z/OS perspective, the replacement of the two members with a member having two fields is not 100% binary compatible for all usage. At least if the `basic_ios` specialization is used as a non-virtual base class, any derived class members that could be allocated in the padding following the `bool` would now move. This could be preemptively avoided if the new class type is given a user-provided copy constructor or destructor and the new member made `[[no_unique_address]]`. I don't know if `[[no_unique_address]]` is usable is some form under C++98/03 though.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D124555/new/
https://reviews.llvm.org/D124555
More information about the libcxx-commits
mailing list