Coverity SCANを使用して小さなLibRawプロジェクトをチェックする際の注意事項を読みました。 記事から興味深いものは見つかりませんでした。 PVS-Studioアナライザーが何かを見つけられるかどうか試してみることにしました。
リボー
LibRawは、デジタルカメラ(CRW / CR2、NEF、RAF、DNGなど)から受信したRAWファイルを読み取るためのライブラリです。 ウェブサイト: http : //www.libraw.org/
Coverity SCANによる検証
そして、PVS-Studioを使用してプロジェクトをテストするようになった記事「 C ++の静的解析について 」があります。 記事の主要部分を簡単に引用してください。
Coverity SCAN:107件の警告。そのうち約3分の1は影響が大きいものです。
ハイインパクトから:
Microsoft STLのピース10
この種の外観の一定量:
int variable; if(layout==Layout1) variable=value1; if(layout==Layout2) variable=value2;
そして、これには警告が出されますが、初期化された変数ではなく、不正確に言います。 私は彼の一般的な感情に同意するので、これをしないでください。 しかし、実際には2種類のレイアウトがあります。これは呼び出しコードで明確に述べられています。 つまり マシンには、これが「大きな影響」ではなく、単に不正確であることを認識するのに十分なデータがあります。
32〜64ビットに拡張するときに符号なしショートを示す一定数の警告は、一口を傷つける可能性があります。 私はこれについて議論したくありません-正式には機械は正しいのですが、実際には写真の大きさはこれらの符号なしのショートで生きており、今後数年で32767に成長しません。
つまり 再度、それを修正する必要はありません-このサブジェクトエリアの場合。
「影響が大きい」で見つかった他のすべての問題は、単なる誤検知です。 つまり コードは完璧ではありません(dcrawからこのコードを見たはずです!)が、見つかったものはすべてエラーではありません。
PVS-Studioによる検証
次に、PVS-StudioアナライザーがCoverityの後に何かを見つけることができるかどうかを見てみましょう。 もちろん、スーパーエラーを見つけることは期待できませんが、試してみるのはまだ面白いです。
PVS-Studioアナライザーは、46個の一般的な警告メッセージ(1番目と2番目の重大度レベル)を生成しました。
私にとって興味深いと思われるコードスニペットを確認することをお勧めします。
タイプミス
void DHT::hide_hots() { .... for (int k = -2; k < 3; k += 2) for (int m = -2; m < 3; m += 2) if (m == 0 && m == 0) continue; else avg += nraw[nr_offset(y + k, x + m)][kc]; .... }
警告PVS-Studio:V501「&&」演算子の左右に同じ副次式があります:m == 0 && m == 0 dht_demosaic.cpp 260
どうやらタイプミスを扱っているようです。 ほとんどの場合、チェックは次のようになっているはずです。
if (k == 0 && m == 0)
同じフラグメントがaahd_demosaic.cppファイルにもあります(199行目)。
優先業務
int main(int argc, char *argv[]) { int ret; .... if( (ret = RawProcessor.open_buffer(iobuffer,st.st_size) != LIBRAW_SUCCESS)) { fprintf(stderr,"Cannot open_buffer %s: %s\n", argv[arg],libraw_strerror(ret)); free(iobuffer); continue; } .... }
PVS-Studio警告:V593「A = B!= C」という表現を検討することを検討してください。 式は次のように計算されます: 'A =(B!= C)'。 dcraw_emu.cpp 468
操作の優先順位に関連するエラー。 最初に、比較「RawProcessor.open_buffer(iobuffer、st.st_size)!= LIBRAW_SUCCESS」が実行されます。 次に、この比較の結果が変数「ret」に書き込まれます。 エラーが発生すると、間違ったエラーコードがファイルに出力されます。 重大な欠陥ではありませんが、それについて話す価値はあります。
負のシフト
unsigned CLASS pana_bits (int nbits) { .... return (buf[byte] | buf[byte+1] << 8) >> (vbits & 7) & ~(-1 << nbits); .... }
警告PVS-Studio:V610未定義の動作。 シフト演算子 '<<を確認してください。 左のオペランド '-1'は負です。 dcraw_common.cpp 1827
負の値をシフトすると、未定義の動作が発生します。 これらのトリックはよく使用され、プログラムは動作するふりをします。 しかし実際には、そのようなコードに依存することはできません。 あなたはここで負の数のシフトについてもっと読むことができます: フォードを知らないで、水に入らないでください。 パート3 。
同様のシフトはここにあります:
- dcraw_common.cpp 1851
- dcraw_common.cpp 2085
- dcraw_common.cpp 2814
- dcraw_common.cpp 6644
奇妙な断片
void DHT::illustrate_dline(int i) { .... int l = ndir[nr_offset(y, x)] & 8; l >>= 3; l = 1; .... }
PVS-Studio警告:V519「l」変数には値が連続して2回割り当てられます。 おそらくこれは間違いです。 行をチェック:671、672。dht_demosaic.cpp 672
おそらくこれは間違いではなく、「l = 1」が具体的に書かれています。 ただし、コードは疑わしいようです。
別の不審な場所を次に示します。
void CLASS identify() { .... if (!load_raw && (maximum = 0xfff)) .... }
PVS-Studio警告:V560条件式の一部は常に真です:((imgdata.color.maximum)= 0xfff)。 dcraw_common.cpp 8496
おわりに
どちらのアナライザーもほとんど見つかりませんでした。 これは小規模なプロジェクトでは自然なことです。 ただし、LibRawをテストするための実験を行うことは依然として興味深いものでした。