クリップボードの不具合に対処したい

[berryzplus]

問題内容

• INT_MAXより大きなバイト数のテキストのクリップボードへのコピーが行えるようにする変更 #2067

クリップボードに入れるデータ形式を意図せず変えてしまっている。

INT_MAXを超えるためにデータ形式 SAKURAClipWのサイズフィールドを int → size_t に変更しています。

ビルド種類	sizeof(int)	sizeof(size_t)	説明
Win32	4バイト	4バイト	格納サイズはINT_MAXを越えられない
x64	4バイト	8バイト	格納サイズはINT_MAXを越えられる
ARM64	4バイト	8バイト	格納サイズはINT_MAXを越えられる

再現手順

最新の開発版サクラエディタでコピーしたテキストを、古いサクラエディタに貼り付けようとするとクラッシュします。

再現頻度

不明です。
再現しない場合もあるかも知れません。

問題のカテゴリ

• プログラムの動作上の問題
  • GitHub ビルド版
  • ローカルビルド版

x64ビルド、ARM64ビルドでのみ発生する問題です。

いろんな考え方がありそうですが、とりあえずなんかマズそうです。

環境情報

• OS バージョン
  関係ありません。
• サクラエディタバージョン
  masterの INT_MAXより大きなバイト数のテキストのクリップボードへのコピーが行えるようにする変更 #2067 をマージした以降のバージョンで発生します。
• PC情報
  関係ありません。

スクリーンショット

[beru]

SAKURAClipW 形式ですが32bitと64bitで互換性が無い事自体はしょうがないとして、形式が異なるという事をプログラム側が認識出来ていないのが良くないですね。なので SAKURAClipW64 形式を別途作るべきな気がします。そして64bitビルドでは従来の SAKURAClipW 形式はペーストには対応するけれども、CClipboard::SetText においてはコピーは行わないようにして良いと思います。というか CClipboard::SetText でのクリップボードへのコピーって複数形式の分をコピーしているとメモリの無駄遣いになるような気がしますが、CF_UNICODETEXT 形式だけだとまずいのでしょうか？

[berryzplus]

かなりめんどくさい話なんですが、
SAKURAClipW 形式にはもともと「仕様上の課題」があるので
本質的には「使用すべきでない」と考えています。

形式	説明
CF_UNICODETEXT	UTF-16LEの文字列（≒NUL終端文字列）を連携する
SAKURAClipW	UTF-16LE拡張のバイナリデータを格納する

UTF-16LE拡張の「拡張部分」を有効に扱うには、変換元の文字コードセットが分かっている必要があります。
現状のインターフェースでは CF_UNICODETEXT と変わらないデータを連携しています。
元の「文字コードセット」が分からないと拡張データにする意味はなく、
CF_UNICODETEXT には「UTF-16LE拡張 のデータを含めてはいけない」ので、
現状だとかなりダメダメな感じになってます。

SAKURAClipW64 形式を追加する意味はあるけど、要らんはず。
SAKURAClipW 形式って「そもそも要る？」に対しても、要らんはず。

自分の認識的には「とりあえずクラッシュするのマズくね？」で「対応しといたほうがよくね？」です。

[berryzplus]

ただのポエム。

CClipboardクラスの存在自体が混乱のもとかも知らんです。

CClipboadクラスのコメントには「将来的にはクリップボード関連の処理をここにまとめたい」みたいなことが書いてある。

でも実際には、クリップボード関連の処理はあちこちに分散していて。

なんでかな？とよくよく見てみると、実質的に「コピーされたテキスト」を表すクラス CDataObject が CClipboard とは別に存在している。

「サクラエディタでコピーできるデータ」の定義は全部 CDataObject に寄せてしまい、CClipboardでは本当にクリップボードの出し入れだけを行うようにしたらロジックがすっきりするように思う。

クリップボード関連の gtest、出力ログが超キタナイのも気にはなるよね。

[berryzplus]

超キタナイログ。