ds14050
ds14050
>.NET の 4.6.1 以降が必要って書かれてました。 そのあたりのバージョンです。すでに MS に見放されているため新しいドットネットはインストールさせてくれないんです。
おそらく NullObject パターンや Optional 型を使うように、いい感じに NULL を許容(無視)したかったんだと思います。 C++ で NullObject パターンはクラスごとに異なる NullObject クラスを用意して継承して、かえって大仰なことになりそうです。 std::optional は C++17 だそうです。
`if (! this) {} else {}` という、何かの嫌がらせかというようなコードが CPrintPreview.h に見つかりました。そこでこんなパターンにしてみました>`if\s*\([^)]+(?=\bthis\b)`。偽陽性は多いですが見逃しよりはましです。 しかしこれでも `this ? A : B` 型の(自分が好む)コードは見つけられません。
これって原理的に無理なことをしようとしているわけではないんですよね。ただ未定義領域であるためにコンパイラに最適化を行う裁量が与えられていて、プログラマの利益にならない最適化のための最適化を行うコンパイラを使うとクラッシュするわけです。最適化を行わせなければ解決する問題です。 お世辞にもお行儀がいいとは言えませんが、大幅な書き直しをしなくてもこのパッチで -Os オプション付きでも起動直後にクラッシュすることがなくなります>[nullpofix.txt](https://github.com/sakura-editor/sakura/files/2569555/nullpofix.txt) 一応試してみましたが ~0 では結論が見えているためにコンパイラを出し抜くことはできませんでした。~1 が問題にならないと考えたのは、ポインタが(一般に)奇数アドレスに置かれることがないことを利用して Ruby の処理系がその 1 ビットに情報を埋め込んでいるという、大昔に聞いた話が元です。自分にはその話の確からしさを推定できるだけの知識もありません。 実際のところ &~1 が問題になるのは、有効な this ポインタが 0x1 という値を持っていたときにヌルポだと誤解してしまうという１点のみです。ありえないでしょう。そしてたぶんコンパイラはその可能性を棄却できない。
この13件で全部だと思います。173件から目視で絞りました。CMyWnd.h が条件演算子タイプでした。対応して nullpofix.txt を更新しました。 ``` □検索条件 "(?| software| code)" 検索対象 *.* !*.svn-base フォルダ sakura_core\ (サブフォルダも検索) (単語単位で探す) (英大文字小文字を区別する) (正規表現:bregonig.dll Ver.2.00 with hitend(). with Oniguruma 5.9.2) (文字コードセットの自動判別) (一致した行を出力) sakura_core\doc\layout\CLayout.h(70,39) [UTF-8]: CLogicInt GetLogicLineNo()...
取り込みの可能性が示されれば nullpofix.txt を PR にしますが、コードの構造を変えずに簡便にクラッシュを回避できるとはいえ「MinGW ビルドのために」「コードの可読性を落とす」「ワークアラウンド」であるために反対意見を予想しています。
>正しくは呼び出し元でチェックすべきなのでしょうが、一体どのくらい修正が必要になるんですかね？ 途中までやりましたが大変に面倒でした。ワークアラウンドに気がついてしまってはもうやるつもりがありません。 >調べるには assert(this != NULL) を入れた上でデバッグモードで動かしてみるのか その assert と同等のチェックを(規格上は)無意味なものだと取り除く最適化がクラッシュの原因です。 (追記) すべての呼び出し元ではなく NULL になり得るフローだけを洗い出して修正する手がかりにしようということでしょうか。それも泥縄式のワークアラウンドです。
EditNode へのポインタを一時変数に保存するというのが機械的に行える、つまりはリファクタリング的な手法だと思います。
>http://www.kt.rim.or.jp/~kbk/zakkicho/10/zakkicho1003c.html#D20100321-3 URL を見て嬉しくなっちゃいました。最近ずっと更新がないんですけどブックマークしてるところです。正規表現とか GREP の情報が豊富です。(雑談でした) 雑談だけではなんなので…… >前提として「需要のあるなし」を把握しとかないといけないと思ってます。 以前は日本語ユーザーにありがちなこととして、階層が深くなると文字数の倍の早さでサイズ上限に近づいていって、パスが長すぎるとエクスプローラーに拒絶されたものですけど、最近はそういうこともありませんね。