爲C++項目報告的奇怪Klocwork問題

我發現Klocwork報告的一些問題很奇怪。例如 -爲C++項目報告的奇怪Klocwork問題

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

Time_Critical_Section cs(*m_pMutex);

對於上面的代碼Klocwork報告NULL指針取消引用。但我認爲這不是一個有效的問題。就好像指針爲null一樣，它將從函數返回並且不會有機會訪問指針。但斯蒂爾克洛克工作報道這是一個問題。

的另一個問題是 -

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

用於上述代碼Klocwork的說上面的代碼部分可引起緩衝區溢出，「的buf」的數組索引可以是出界。但是我們確認name變量不會超過1000字節。但Klocwork仍然將此視爲一個問題。

我們需要讓我們的代碼無錯誤，最終的代碼不應該包含任何Klocwork的問題。任何人都可以提出一種有效的方法來克服上述問題嗎？

來源

2014-03-04 Naseef Ur Rahman

是'm_pMutex'還是'm_pMutex.get（）'指針？ –

m_pMutex是一個智能指針提升。你需要檢查智能指針調用get，我的意思是檢查m_pMutex的px。 –

對於第二個問題，使用'snprintf（）'可能會刪除Klocwork警告。 –

找到空指針解除引用問題的根本原因。讓我們解釋爲什麼這段代碼獲得空指針解引用。

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）;」它在開放塊中找到它，雖然它已經被檢查過了，如果指針是空的，我們已經從值爲-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-12 09:43:51

這是非常棒的反klocwork post =）。感謝您發佈答案... –

爲C++項目報告的奇怪Klocwork問題

回答

相關問題