
不具合の再現
必ず再現する訳ではなく、正常に処理されるものもあるようだ。違いは不明。
対象ファイルの行頭は1行目が短く、2行目が長い。
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
GitHubになって初めての不具合報告です。
デフォルトの報告Formがないけど、これでいいのかな?
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 );
std::wstring line、szAboutはWCHAR szAbout[50]。一番簡単な対処策は
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() メソッドを検索しました。
そして知る衝撃の事実(笑)
この関数は、文字列sにヌルオブジェクトを追加しない。
std::string は C のヌル終端文字列とは違いますし、c_str() がいわば互換性のための例外としてヌル終端に言及するだけなんでしょうか。
こちらまだ正常に動作していないので reopen します。
しかし、原因調査の過程で同箇所に不具合があることが分かったので #1244 を作成しました。
このissueのクローズは #1244 のマージ後としたいです。
@ds14050 さん
std::string は C のヌル終端文字列とは違いますし、c_str() がいわば互換性のための例外としてヌル終端に言及するだけなんでしょうか。
C++03までは必ずしも内部的にNULL終端されている必要は無かったようです。C++11以降ではNULL終端前提になったんだとか。
C++11 以降では内部データとしてヌル終端が存在していることが保証されたんですね。
CoW はリソース環境の変化もあり手放しで採用できる技術ではなかったようですし、最低限のスペースが必要になるとしても存在を保証するメリットの方が大きいという判断なんでしょう。初期化しない std::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;
};
~~~
~
size_type
capacity() const _GLIBCXX_NOEXCEPT
{
return _M_is_local() ? size_type(_S_local_capacity)
: _M_allocated_capacity;
}
~
~
bool
_M_is_local() const
{ return _M_data() == _M_local_data(); }
~
ヌル文字1バイトと言わず8バイト/16バイトくらいの配列を、少数の文字配列用とヒープに確保したサイズの記憶用として兼用しているみたいです。
このissueのクローズは #1244 のマージ後としたいです。
これを待ちます!
このissueのクローズは #1244 のマージ後としたいです。
これを待ちます!
マージしたので閉じます。