「静的プログラム解析ツールの実力は？」記事へのコメント

そこそこ出来る人による使用例を求む

[Anonymous Coward]

静的プログラム解析ツールというのは
「ダメダメな人にでも使わせるとダメダメなプログラムがそれなりの出来になるツール」ではなくて、
「それなりの人に使わせることでそれなりなプログラムがなかなか良い出来になるツール」なのでしょう。
「すごい人に使わせてもすごいプログラムが完璧なできになるツール」でもないと思います。むしろこの場合は、ツールの出来によっては「見当はずれな警告しか出ないでストレスの元にしかならないツール」であるかもしれません。

「こーんなヤツにこんなツールを使わせても役には立たないよ！」という話ばかりでなく、

実際、次世代静的プログラム解析ツールを導入することで開発方法やテストサイクルに変化はあるのだろうか？　新しい解析ツールは既存のものよりそんなに実力が違うのだろうか？

こちらの話も聞きたいのですが。「甲のツールを使っていたらこんな警告が出て、こんなバグを見つけたよー」とかいう話もよろしく。

Re:

[Anonymous Coward]

使っているツールの名前は出しませんがなかなか優秀だと感じました。
ごくまれに、なんで警告が出るんだ出るわけないだろってこともあります。

警告の内容は例えば
１．int型に対しビット演算を行うと「整数型に対してビット演算を行っています」ってな感じの警告が出ます。
　　この場合unsigned int型でビット演算を行えば警告は出ません。

２．もしchar型の範囲が-127～128だった場合
　　0xffを代入しようとした場合これも警告が出ます。
　　型の範囲外の値を代入しようとしているためです。
　　charの範囲は環境により異なるためなんともいえませんが。

３．short型(16ビット)にint型

Re:

[Anonymous Coward]

アセンブラ経験があればそれほど不思議な警告ではないような。

1.は、符号付き整数にたいしてビット操作をおこなうのは、符号の反転が
発生することがあるから行儀よくない、ということだろうし。
（ビット列としてみるなら符号無し整数を使うべき)

2.も同様。signed charに対して0xffを代入するのは、まちがえて255を
代入しているのか-1の8bit表現を16進数に書き直したものかが明示的で
ないためだと思われます。

3.は、処理系のエンディアンによってint型のbyte列のどこがshort型に
入るかがちがってくるからでしょう。

4.は、for文の条件は符号無しの条件分岐になるので、常に真ですよ。

Re:そこそこ出来る人による使用例を求む

[Anonymous Coward]

C言語の話だとして
> 3.は、処理系のエンディアンによってint型のbyte列のどこがshort型に
> 入るかがちがってくるからでしょう。
これは違うでしょう。
int i = 123;
short s;
memcpy(&s, &i, sizeof(short));
とかしてるわけじゃないし。