bit_cast 実装イメージと未定義動作の話

[k-satoda]

@faithandbrave さんの commit 1060be9 の bit_cast.md を見て気になったことです。
概要より:

低レイヤーのプログラムでは、同じビットを維持してほかの型に解釈し直すことが必要とされる。その際、reinterpret_castや共用体を使用すると、Strict Aliasing規則に抵触してしまい未定義動作になってしまう。そのような目的にはstd::aligned_storageとstd::memcpy()を組み合わせて使用することになるが、それを簡単に使用できるようにしたのが本関数である。

備考にある実装イメージより:

template<typename To, typename From>
To bit_cast(const From& from) noexcept { // 実際には、さらに要件チェックが行われる
  // To型のオブジェクトに直接memcpyするのではなく、アライメント調整した領域にmemcpyして、
  // その領域をTo型に再解釈キャストする。
  typename std::aligned_storage<sizeof(To), alignof(To)>::type storage;
  std::memcpy(&storage, &from, sizeof(To));  // memcpyはconstexprではないため、
                                             // コンパイラが特殊な実装をする必要がある
  return reinterpret_cast<To&>(storage);
}

僕の知る限りこの return reinterpret_cast<T&>(storage) は return reinterpret_cast<To&>(from) と同じく
実際のオブジェクトと無関係な型でのアクセスを起こすという理由で未定義動作の範囲内にあり、
違うのは memcpy を挟むことで現代のコンパイラで実際に誤動作に至る可能性をほぼ無くせること、
と認識しています。（この効果を一定条件下で規定しちゃおうというのが https://wg21.link/P0593 の目的、と。）

（↑の認識が正しいとして・・・）
現状の記事のままだと、概要の文面と合わせてこの aligned_storage と memcpy を使ったコードが
未定義動作を回避するものと読み取られそうでヤダなーと思ったんですが、だからといって
既存の手法や実装方法に関する記述をざっくり削除するというのも望ましくないものと思います。
というわけで、いったん issue にしてみることにしました。
認識の正誤や記事の改善方針について意見もらえるとうれしいです。

[yumetodo]

https://cpprefjp.github.io/reference/type_traits/aligned_storage.html
には

template <class T, std::size_t Capacity>
class StackContainer {
  // 長さ：sizeof(T) * Count、
  // アライメント：alignof(T)
  // でアライメント調整された領域を作る
  typename
    std::aligned_storage<sizeof(T) * Capacity, alignof(T)>::type
  storage;

  std::size_t size_ = 0;

  T* data()
  {
    return static_cast<T*>(static_cast<void*>(&storage));
  }

という例が載っているんですが、このstatic_cast二段重ねも問題があるのでしょうか？

[onihusube]

static_castの二段重ねは同じことをするreinterpret_cast1回と同じです
結局キャスト後のポインタの参照先へのアクセスがstrict aliasing ruleに違反するはず

[yumetodo]

というか前にどっかでその話聞いたと思ったら
std::aligned_storageを正しく使うためのstrict aliasing rulesとstd::launder - 地面を見下ろす少年の足蹴にされる私
https://onihusube.hatenablog.com/entry/2018/07/22/040059
これだ、placement newの戻り値を掴んで離すなもしくはstd::launderしろっていう
これの作者さんでしたか・・・。

[onihusube]

それ盛大に間違ったこと書いてたので恥ずかしい😅
placement newの戻り値を掴んで離すな、という所は間違ってないはずですけど、それをbit_castに適用しようとするとデフォルトコンストラクトかコピー/ムーブコンストラクトを要求してしまいます・・・

[yumetodo]

そういえば @yohhoy さんとやり取りされていたような薄い記憶

https://t.co/w5mqNbdfay 例えばint x2 = *std::launder(reinterpret_cast<int*>(&data));がOKになる理由は、アクセス時型情報を根拠とするstruct aliasing ruleとは無関係であり、launder関数によってobject lifetimeに基づいた最適化(可能性)を抑止できるから というのが私の解釈でした。

— yoh (@yohhoy) March 22, 2019

[faithandbrave]

反応が遅くなってしまってすいません。
bit_castについては説明を書き足すとして、aligned_storageの例は、以下のように直せば解決でしょうか？

#include <iostream>
#include <type_traits>

template <class T, std::size_t Capacity>
class StackContainer {
  // 長さ：sizeof(T) * Count、
  // アライメント：alignof(T)
  // でアライメント調整された領域を作る
  typename
    std::aligned_storage<sizeof(T) * Capacity, alignof(T)>::type
  storage_;

  T* ptr_ = nullptr;
  std::size_t size_ = 0;

public:
  void push(T value)
  {
    // 未初期化領域に要素を作る
    if (size_ <= 0) {
      ptr_ = new (&storage_) T(value);
    }
    else {
      new (reinterpret_cast<T*>(&storage_) + size_) T(value);
    }
    ++size_;
  }

  T& front()
  {
    return *ptr_;
  }

  ~StackContainer()
  {
    for (std::size_t i = 0; i < size_; ++i) {
      (ptr_ + i)->~T();
    }
  }
};

int main()
{
  StackContainer<int, 3> cont;
  cont.push(1);

  std::cout << cont.front() << std::endl;
}

[faithandbrave]

サンプルコードはもともとBoost.Containerのstatic_vectorを参考にしていたのですが、あちらが持っているaligned_storageにはStrict Aliasing回避用にdataメンバ変数があってそれを使ってるみたいでした。

[faithandbrave]

bit_castの実装イメージに説明付け足しを行いました。

[k-satoda]

（ひとまず aligned_storage の件について。何か話が広がりそうであれば
別 issue にしてもらったほうがいいと思います。）

@yumetodo aligned_storage の例にあるキャストは、 bit_cast の例のものと
違ってそこに実際に指定した型のオブジェクトが構築されます。これなら、
オブジェクト構築後に使う分にはほぼ問題無いと思います。

C++14 までは reinterpret_cast だけで有効な気配もあったんですけど、
おそらく現実のコンパイラの最適化と合致しなくなって下記の記述が無くなった
C++17 からは、厳密には std::launder() も加えないと未定義動作の範疇に
なります。
https://timsong-cpp.github.io/cppwp/n4140/basic.compound#3

... If an object of type T is located at an address A, a pointer of
type cv T* whose value is the address A is said to point to that object,
regardless of how the value was obtained. ...

@faithandbrave 修正案でこの点については改善されるように思います。
reinterpret_cast<T*>(&storage_) + size_ は ptr_ + size_ のほうが
簡単でよさそうです。

・・・配列オブジェクトを指さない ptr_ や &storage_ への ... + size_ が
未定義動作になるという問題 https://wg21.cmeerw.net/cwg/issue2182 が
気になりましたが、回避しようと思うと aligned_storage ではなく
生のバイト配列を使う形にするぐらいしか思いつかないですし、
bit_cast の件と違って未定義動作について誤解を誘うような記述も無いので、
当面はこのままでもいいかと思います。

[k-satoda]

@faithandbrave 変更 24ba817 見ました。
実装イメージが未定義動作を回避するものではないことを示すようになるのは
改善になると思います。でも、概要の文面にある「std::aligned_storageと
std::memcpy()を組み合わせて使用」もそのままとはいかないように思います。
（typo も見つけてます。 ×"String Aliasing規則" ○"Strict Aliasing規則"）

改めていくらか調べた結果として、以下の点から aligned_storage への言及を
削除してしまったほうがいいんじゃないかと思っています。

• bit_cast の提案 http://wg21.link/P0476 登場以前に aligned_storage と
  memcpy で問題を回避していたという実例が、少なくとも簡単な検索では
  見つけられなかったこと。
• p0476 提案者の LLVM へのコミット https://reviews.llvm.org/rL342739 を
  見るに、提案者もこの reinterpret_cast による aligned_storage からの
  読み取りが未定義動作になることを認識していなかったようであること。
• http://wg21.link/P1413R1 (.pdf) によれば、 aligned_storage は
  そのインターフェースに問題があり、非推奨とされる見込みもあること。

具体的な変更として、概要はこんな感じ:

低レイヤーのプログラムでは、同じビットを維持してほかの型に解釈し直したいことがある。その際、reinterpret_castや共用体を使用すると、Strict Aliasing規則に抵触して未定義動作になってしまう。安全な方法としてはstd::memcpy()を使用するなどがあるが、面倒なことなどから前述の危険な方法が多く見られた。そこで、同等の操作を簡単で安全にできるようにしたのが本関数である。

実装イメージはこんな感じ:

template<typename To, typename From>
To bit_cast(const From& from) noexcept { // 実際には、さらに要件チェックが行われる
  // この実装ではTo型がデフォルト構築可能である必要があるが、C++20のbit_castでは必要無くなる
  To result;
  std::memcpy(&result, &from, sizeof(To));  // memcpyはconstexprではないため、
                                            // コンパイラが特殊な実装をする必要がある
  return result;
}

こんな感じで、周辺の見直しも含めた変更を入れるのがいいかと思ってます。
どうでしょう？

[yumetodo]

aligned_storage は
そのインターフェースに問題があり、非推奨とされる見込みもあること。

なんと・・・。

aligned_storage への言及を削除する方向に同意します。

[faithandbrave]

aligned_storageとbit_castのページを修正しました。
問題あればreopenするか、直接修正するかお願いします。

それと、本Issueはbit_castに関する問題でしたが、便乗で別件が混じってしまって議論と解決が難しかったです。ひとつの問題に集中できるよう、次からは便乗はせず別Issueとして起こしていただけると助かります。