Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DIFF差分とウィンドウ一覧ダイアログでファイル名がMAX_PATHぎりぎりだと落ちてしまう不具合の修正 #1413

Merged
merged 2 commits into from
Sep 27, 2020

Conversation

usagisita
Copy link
Contributor

@usagisita usagisita commented Sep 26, 2020

PR の目的

259文字のファイル名のファイルを開いて、ダイアログを表示しても落ちないで表示できるようにします。

カテゴリ

  • 不具合修正

PR の背景

259文字のフルパスを持ったファイルを開いていると、DIFF差分ダイアログとウィンドウ一覧ダイアログを表示したときに、
セキュリティのバッファ長不足によるハンドラー呼び出しの例外で落っこちます。

PR のメリット

このケースでは落ちないようになります。

PR のデメリット (トレードオフとかあれば)

単純に配列長を伸ばしので、スタックを余分に消費します。

テスト内容

マイドキュメント配下、AppData以下の場合は「ファイル名表示」で短く表示する設定を削除ないしダミー文字を追記などして、無効にします。
「%Personal%」→「★%Personal%」のように書き換えます。
上の「長いパスの省略表示」を無効に設定します。
→フルパスがそのまま表示されるようになります。

もうひとつのサクラエディタで259文字のフルパスのファイルを開いておきます。
DIFF差分表示ダイアログを表示しようとすると、クラッシュします。

差分を適用してコンパイルし、再度表示してみると今度は落ちません。

ウィンドウ一覧ダイアログでも同様に、表示しただけで落ちます。

ローカル変数のバッファ長が[_MAX_PATH]になっています。
しかし表示には「アクセス用文字1文字」「セパレータのスペース」「フルパス」「 [UTF-8]などの文字コード」が
表示されるので、最大では_MAX_PATH+30程度は必要です。

PR の影響範囲

関連 issue, PR

参考資料

@AppVeyorBot
Copy link

Build sakura 1.0.3111 completed (commit bd766fd3c6 by @usagisita)

@beru beru added the 🐛bug🦋 ■バグ修正(Something isn't working) label Sep 26, 2020
Copy link
Contributor

@beru beru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

落ちなくなることを確認しました。

落ちる不具合は共通設定のファイル名表示の長いパスの省略表示の設定を無効化する事で再現しました。

259文字のフルパスがウィンドウ一覧表示で全て表示されずに最後の数文字が欠ける事が気になりましたが、表示の問題なのでコーナーケースで落ちる不具合が解消された事に比べるとどうでも良い気がします。

@@ -239,7 +239,7 @@ void CDlgDiff::SetData( void )
EditInfo *pFileInfo;
int i;
int nItem;
WIN_CHAR szName[_MAX_PATH];
WCHAR szName[512];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

このままで問題ないと思いますが、あえて従来基準のアフォコメント付けときます。

_MAX_PATH(=260) を 512 に変える根拠はなんでしょうか?

事象の分析で「最大で _MAX_PATH + 30程度必要」と判断したのに、512としたのは何故?
512 = _MAX_PATH × 2 - 108 だと思うので、512の根拠が良く分かりませんでした。

また、最終的な値を 512 とするにしても、パス文字列の最大長(_MAX_PATH)に起因する値であるとわかる工夫をしておくのがベターだと思いました。

@usagisita
Copy link
Contributor Author

512なのは、既存の似たような処理のダイアログ、ファイル比較だったかな、に合わせたからですからです。
しかし、文字コードのコードページが固定で[100]が多いようなので(これも根拠とかなさそう)、[MAX_PATH+100]とかのほうがって確かに思いました。
ここはちょっとセンスなかったですね。ぐぬぬ。
近い将来的には、もっと長いパス処理に対応したstd::wstringなりにするんだろう、ということで、ひとつ。

@beru beru merged commit 120a20c into sakura-editor:master Sep 27, 2020
@usagisita usagisita deleted the hotfix/long_long_file_name branch September 27, 2020 14:41
@usagisita
Copy link
Contributor Author

259文字のフルパスがウィンドウ一覧表示で全て表示されずに最後の数文字が欠ける事が気になりましたが、表示の問題なのでコーナーケースで落ちる不具合が解消された事に比べるとどうでも良い気がします。

これについて、調べてみたのですが、いくつかのサイトに言及があり、
MSDNのLVITEMのページに
https://docs.microsoft.com/ja-jp/windows/win32/api/commctrl/ns-commctrl-lvitemw

Note that although the list-view control allows any length string to be stored as item text, only the first 260 TCHARs are displayed.

と書かれていて、260文字までしか表示しない、仕様だそうです。
これを超えたければ、オーナードローをしないといけないということだと思われます。
またひとつ、MAX_PATH制限を超える壁が増えた感じです。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛bug🦋 ■バグ修正(Something isn't working)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants