[スレッド全体]
▼ 2015/1/10 (土) 22:56:58 suzz 　
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
[2234] 紅桜の #if 0/#if 1 コード不具合について
> ○：範囲外アクセス
> 読み込みだけでは、バッファオーバーランとは言わないと思う。全然違うがな。

よろしければ、どのあたりが範囲外アクセスを行っているか、教えていただけないでしょうか？


ちなみに、

$endif はくだらないミスですね。。。
文字数が合っているので、かろうじて不具合にはなっていないようですが。

プリプロセッサに大文字は無いようなので、wmemicmp を使用しているのは不具合です。
おそらく、CBlockComment.cpp を流用したので、あまり考えず wmemicmp を使ってしまったのだと思います。
▼ 2015/1/11 (日) 03:19:49 もか 　
INCM1.23a
[2235] RE: 紅桜の #if 0/#if 1 コード不具合について
>> ○：範囲外アクセス
>> 読み込みだけでは、バッファオーバーランとは言わないと思う。全然違うがな。
>
>よろしければ、どのあたりが範囲外アクセスを行っているか、教えていただけないでしょうか？
これ、CStringRefは元がCNativeWだった場合は、NUL文字が末尾についていることを保証できるので、
呼び出し元を含めたコード全部を考慮にいれた場合は、大丈夫みたいです。
すみません。


細かく対応しようとすると面倒がおおいですね。
行をまたいだでプリプロセッサがコメントアウトされた場合
/*
#endif
*/
とか。
厳密にはOKなのか知らないのですが、ifの直後に括弧がある場合とか、
#if 0
#if(1)
#endif
#endif

memcmp/wmemcmpって、
比較が一致しなかった次の文字にはアクセスしたらいけないのですよね？
先頭から1文字づつ比較しないといけなくて、
intとか8バイト以上とかで一致するか見るだけの場合にループで書いたのほうが速いとかありそう。
まぁ今のマシンは100MBをコピーしても一瞬だったりするから気にしたことないけど。
▼ 2015/1/11 (日) 04:04:18 もか 　
INCM1.23a
[2236] RE2: 紅桜の #if 0/#if 1 コード不具合について
>比較が一致しなかった次の文字にはアクセスしたらいけないのですよね？
気になったんで(英語はよく分からんから)JIS X 3010:2003をwebで閲覧してみたけど、(w)memcmpの箇所に
有効バッファ長(n)のうち一致しなかった文字の後ろにアクセスしちゃいけない
とは書いてないので、
memcmp( "ab", "abcdefgh", 8 );
こういうのは、厳密な定義によるなら範囲外アクセスになるかどうかは実装依存かも。
サクラのほかのコードでも引数のs1,s2両方の長さが、n未満の場合がある使い方をしてるっぽいので微妙だ。
▼ 2015/1/12 (月) 16:55:15 suzz 　
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0
[2237] Re2: 紅桜の #if 0/#if 1 コード不具合について
> >よろしければ、どのあたりが範囲外アクセスを行っているか、教えていただけないでしょうか？
> これ、CStringRefは元がCNativeWだった場合は、NUL文字が末尾についていることを保証できるので、
> 呼び出し元を含めたコード全部を考慮にいれた場合は、大丈夫みたいです。

ありがとうございます。
文字の比較に memcmp(wmemcmp) を使うのも微妙な感じがするので、wcsncmp で比較する形にしようと思います。
(条件判定１回分省略したい・・・とも思わないので。)

> 細かく対応しようとすると面倒がおおいですね。
私は「いい加減」なので、あまり細かく対応せずとも、現状のブロックコメントより改善されれば良いかなと思っています。

#if 0/ #if 1 は、往々にしてコメントアウト目的のコードですので、
色分け表示する以前に消せばいいのですが、それを許してくれない現場も残っています。
[▼次のスレッド]
INCM/CMT
Cyclamen v3.81
[ut:0.010][st:0.000]