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

Created on 21 Apr 2020  ·  15Comments  ·  Source: sakura-editor/sakura

  • 状況
    UTF-8 BOM付ファイル編集中、タイプ別設定で SJIS エンコードされたキーワードヘルプファイルを指定したとき、説明が文字化け表示し、またクラッシュした。
    コメント 2020-04-21 113513
    登録(挿入・更新)を強行すると、場合によって(多分、使用文字による?)はCrashする。
  • 不具合の再現
    必ず再現する訳ではなく、正常に処理されるものもあるようだ。違いは不明。
    対象ファイルの行頭は1行目が短く、2行目が長い。

    1. 文字化け
      > ; 関数目次[crlf]
      > ; 使用するマクロの種類により、先頭の'S_'をつける場合とつけない場合があります。>>マクロの関数名について[crlf]
    2. Crach
      > ;===============================================================================[crlf]
      > ;PPA.DLL のヘルプより抜粋[crlf]
  • Version
    サクラエディタ v2.4.0.2688 32bit dev
    (GitHash 1397eca34eeb36dba9d2815316380e06241f4771)
    (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がないけど、これでいいのかな?

🐛bug🦋

All 15 comments

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

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

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

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

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

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

szAbout のサイズチェックが抜けた?>https://github.com/sakura-editor/sakura/commit/e7eaaa6390106bc59c100131b2e1630947436c4a#diff-c362884b87d4d3b2b2df732a6fbc55a1

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

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

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とか指定できんのだろうか?...

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

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

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

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

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

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

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

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

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

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

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

1238 のマージにより、報告された不具合は解消しました。

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

@ds14050 さん

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

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

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(); }
~

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

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

これを待ちます!

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

これを待ちます!

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

Was this page helpful?
0 / 5 - 0 ratings