[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