0

Klocwork によって報告されたいくつかの問題は非常に奇妙です。例えば ​​-

if(NULL == m_pMutex.get())
{
    Log("found unexpected sharedPtr m_pMutex");
    return -1;
}

Time_Critical_Section cs(*m_pMutex);

上記のコードの場合、Klocwork は NULL ポインター逆参照を報告します。しかし、これは正当な問題だとは思いません。ポインターが null であるかのように、関数から返され、ポインターにアクセスする機会がありません。しかし、それでも Klocwork はこれを問題として報告しました。

もう一つの問題は-

 char buf[1000];
 sprintf(buf,"%s",name);

上記のコードについて、Klocwork は、上記のコード部分がバッファー オーバーフローを引き起こす可能性があると述べています。'buf' の配列インデックスが範囲外である可能性があります。ただし、name 変数が 1000 バイトを超えないことを確認しています。それでも、Klocwork はこれを問題として報告しました。

コードにエラーがないようにする必要があり、最終的なコードには Klocwork の問題が含まれないようにする必要があります。上記の問題を克服するための効率的な方法を提案できる人はいますか?

4

1 に答える 1

1

null ポインター逆参照の問題の根本原因が見つかりました。このコードが null ポインター逆参照を取得する理由を説明しましょう。

if(NULL == m_pMutex.get())
{
    Log("found unexpected sharedPtr m_pMutex");
     return -1;
}

Time_Critical_Section cs(*m_pMutex);

Klocwork は、「Time_Critical_Section cs(*m_pMutex);」のポインターをチェックする場合の静的コード アナライザーです。以前にチェックされていても、開いているブロックでそれを見つけ、ポインターが null の場合は、値 -1 で関数から返されます。Klocwork が静的コード解析を行っている場合、開いているブロック内のポインターのアクセス コードとして以前にポインターをチェックしたことは不明です。次のようにコードを変更することで、この問題を解決できます -

if(NULL == m_pMutex.get())
{
   Log("found unexpected sharedPtr m_pMutex");
   return -1;
}
else
{

   Time_Critical_Section cs(*m_pMutex);
   //Do some operations
   return 0;
}
于 2014-06-12T09:43:51.960 に答える