SJISエンコードのキーワードヘルプ辞書を設定するとき表示化け・Crashする

[masamaru-san]

• 状況
  UTF-8 BOM付ファイル編集中、タイプ別設定で SJIS エンコードされたキーワードヘルプファイルを指定したとき、説明が文字化け表示し、またクラッシュした。
  
  登録（挿入・更新）を強行すると、場合によって（多分、使用文字による？）はCrashする。

• 不具合の再現
  必ず再現する訳ではなく、正常に処理されるものもあるようだ。違いは不明。
  対象ファイルの行頭は1行目が短く、2行目が長い。

  1. 文字化け

     ; 関数目次[crlf]
     ; 使用するマクロの種類により、先頭の'S_'をつける場合とつけない場合があります。>>マクロの関数名について[crlf]

  2. Crach

     ;===============================================================================[crlf]
     ;PPA.DLL のヘルプより抜粋[crlf]

• Version
  サクラエディタ v2.4.0.2688 32bit dev
  (GitHash 1397eca)
  (GitURL https://github.com/sakura-editor/sakura.git)
  Compile Info: V1916 WPR WIN601/I800/C000/N601
  Last Modified: 2020/4/19 03:08:18

---

GitHubになって初めての不具合報告です。
デフォルトの報告Formがないけど、これでいいのかな？

[KENCHjp]

GitHubになって初めての不具合報告です。
デフォルトの報告Formがないけど、これでいいのかな？

不具合報告ありがとうございます。
一応、右上のNew Issueボタン押すとＦｏｒｍの選択画面が出るはずなんですが、
いかがでしょう？
本件はこのままでも大丈夫です。

[masamaru-san]

Formについて、素うどん GitHub Issue 窓でした。
OSDNの時みたいなFormか、Feedback Hubみたいなら、エラー報告やらしやすいんですけど…

[KENCHjp]

＞Formについて、素うどん GitHub Issue 窓でした。

すいません、「素うどん」がよくわかりませんが、今右上のNew Issueボタン押していただけると、書き込みひな形の選択画面がでます。
OSDNのチケットのような入力フィールドありのやつがいいかと思いますがいかんせんGItHubはこのようなシステムのようです。

場合によってはＯＳＤＮ側の会議室お使いいただければ比較的メンバー見ています。
残念ながらDiscordはあまりフォローできていません。
以上よろしくお願いいたします。

[ds14050]

szAbout のサイズチェックが抜けた？>e7eaaa6#diff-c362884b87d4d3b2b2df732a6fbc55a1

[berryzplus]

すみません、現象まだ追えていないです。

キーワードヘルプ辞書の辞書ファイル読込は、ドキュメントの文字コード指定と独立しているんじゃなかったかな？とか、そういえば検索速度改善のために二分探索方式に変えたりしたなぁとか色々思うところはある感じです。(ﾏﾃﾏﾃ

issueのテンプレートを用意しているので、issuesページの new issue ボタンを押すとテンプレート選択の画面がでるはずです。

これ ⇨ https://github.com/sakura-editor/sakura/issues/new/choose

この中からどれかを選んでやると
https://github.com/sakura-editor/sakura/issues/new?template=XXX.md
に遷移する仕組みになっています。

手打ちとかで https://github.com/sakura-editor/sakura/issues/new を直接開くとテンプレート適用なしのフォームになっちゃいますね...
default templateとか指定できんのだろうか？...

[berryzplus]

とりあえず @ds14050 さんの調査結果を見て見ました。

- _wcstotcs(szAbout,line.c_str(),_countof(szAbout)); 
+ line.copy( szAbout, line.length(), 0 ); 

• lineはstd::wstring line、szAboutはWCHAR szAbout[50]。
• std::wstring::copy(wchar_t* szDest, size_t nCount, size_t nOffset = 0)
  • コンテキスト的に line から line.length() 文字分 szAbout にコピーする。
  • C-StringをNUL終端する処理が落ちてますね(原因確定)

一番簡単な対処策は
line.copy( szAbout, line.length(), 0 );
　↓
line.copy( szAbout, line.length() + 1, 0 );
とすることです。（通常 line[length()] は '\0' なので。

[berryzplus]

ちなみに こいつ は #1034 の一部です。

[ds14050]

line はコピーに供すべき自身の長さを知っていますから、line.length() の代わりに _countof(szAbout) に基づく値を上限として指定するのではありませんか？ line.copy() メソッドについて調べずに書いていますが。

[ds14050]

line.copy() メソッドを検索しました。

basic_string::copy - cpprefjp C++日本語リファレンス

そして知る衝撃の事実(笑)

この関数は、文字列sにヌルオブジェクトを追加しない。

std::string は C のヌル終端文字列とは違いますし、c_str() がいわば互換性のための例外としてヌル終端に言及するだけなんでしょうか。

[beru]

こちらまだ正常に動作していないので reopen します。

[berryzplus]

#1238 のマージにより、報告された不具合は解消しました。
しかし、原因調査の過程で同箇所に不具合があることが分かったので #1244 を作成しました。
このissueのクローズは #1244 のマージ後としたいです。

[beru]

@ds14050 さん

std::string は C のヌル終端文字列とは違いますし、c_str() がいわば互換性のための例外としてヌル終端に言及するだけなんでしょうか。

C++03までは必ずしも内部的にNULL終端されている必要は無かったようです。C++11以降ではNULL終端前提になったんだとか。

[ds14050]

C++11 以降では内部データとしてヌル終端が存在していることが保証されたんですね。

CoW はリソース環境の変化もあり手放しで採用できる技術ではなかったようですし、最低限のスペースが必要になるとしても存在を保証するメリットの方が大きいという判断なんでしょう。初期化しない std::string にメモリ確保のオーバーヘッドが生じるならヒープの二重確保が約束されるのが嫌すぎますが、賢い人がうまくやるんでしょうね……。

---

さぼらずに読んでみました。

basic_string のデータメンバ(抜粋)

      _Alloc_hider	_M_dataplus;
      size_type		_M_string_length;

      enum { _S_local_capacity = 15 / sizeof(_CharT) };

      union
      {
	_CharT           _M_local_buf[_S_local_capacity + 1];
	size_type        _M_allocated_capacity;
      };

capacity() メンバ関数

      size_type
      capacity() const _GLIBCXX_NOEXCEPT
      {
	return _M_is_local() ? size_type(_S_local_capacity)
	                     : _M_allocated_capacity;
      }

_M_is_local() 関数

      bool
      _M_is_local() const
      { return _M_data() == _M_local_data(); }

ヌル文字１バイトと言わず8バイト/16バイトくらいの配列を、少数の文字配列用とヒープに確保したサイズの記憶用として兼用しているみたいです。

[KENCHjp]

このissueのクローズは #1244 のマージ後としたいです。

これを待ちます！

[berryzplus]

このissueのクローズは #1244 のマージ後としたいです。

これを待ちます！

マージしたので閉じます。