Wie schreibe ich richtig ASSERT Code um zu übergeben/analysieren in msvc?

Question

Visual Studio hat eine Codeanalyse (/analyze) für C/C++ hinzugefügt, um bei der Identifizierung von fehlerhaftem Code zu helfen. Das ist eine nette Sache, aber wenn Sie mit einem alten Projekt umgehen, können Sie von der Anzahl der Warnungen überwältigt sein.

Die meisten Probleme werden generiert, weil der alte Code am Anfang der Methode oder Funktion ein ASSERT ausführt.

Ich denke, dies ist die ASSERT Definition ist im Code verwendet (von afx.h)

#define ASSERT(f)   DEBUG_ONLY((void) ((f) || !::AfxAssertFailedLine(THIS_FILE, __LINE__) || (AfxDebugBreak(), 0))) 

Beispielcode:

ASSERT(pBytes != NULL); 
*pBytes = 0; // <- warning C6011: Dereferencing NULL pointer 'pBytes' 

Ich suche eine einfache, saubere und sichere Lösung lösche diese Warnungen, die nicht bedeuten, diese Warnungen zu deaktivieren. Habe ich erwähnt, dass es in der aktuellen Codebasis viele Vorkommen gibt?

Answer 1

PREFast sagt Ihnen, dass Sie einen Fehler in Ihrem Code haben; Ignoriere es nicht. Sie haben tatsächlich eine, aber Sie haben nur herumgesprochen und es bestätigt. Das Problem ist das: nur weil pBytes in der Entwicklung nie NULL war & Testen bedeutet nicht, dass es nicht in Produktion sein wird. Du gehst mit dieser Eventualität nicht klar. PREfast kennt das und versucht, Sie zu warnen, dass Produktionsumgebungen feindlich sind und Ihren Code eine rauchende, verstümmelte Masse wertloser Bytes hinterlassen.

/rant

Es gibt zwei Möglichkeiten, dieses Problem zu beheben: der richtige Weg, und ein Hack.

Der richtige Weg ist NULL-Zeiger zur Laufzeit zu handhaben:

void DoIt(char* pBytes) 
{ 
    assert(pBytes != NULL); 
    if(!pBytes) 
     return; 
    *pBytes = 0; 
} 

Dies wird zum Schweigen PREfast.

Der Hack soll eine Anmerkung verwenden. Zum Beispiel:

void DoIt(char* pBytes) 
{ 
    assert(pBytes != NULL); 
    __analysis_assume(pBytes); 
    *pBytes = 0; 
} 

EDIT: Here's a link beschreibt PREfast Anmerkungen. Ein Ausgangspunkt sowieso.

Answer 2

Sie scheinen davon auszugehen, dass ASSERT(ptr) irgendwie bedeutet, dass ptr danach nicht NULL ist. Das ist nicht wahr, und der Code-Analyzer macht diese Annahme nicht.

Answer 3

/analyze kann nicht garantiert werden, dass relevante und korrekte Warnungen ausgegeben werden. Es kann und wird eine Menge von Problemen vermissen, und es gibt auch eine Anzahl von falsch positiven (Dinge, die es als Warnungen identifiziert, aber die vollkommen sicher sind und nie tatsächlich auftreten werden)

Es ist unrealistisch zu erwarten, dass Null Warnungen mit/analysieren.

Es hat eine Situation aufgezeigt, in der Sie einen Zeiger dereferenzieren, der es nicht überprüfen kann, ist immer gültig. Soweit PREfast es beurteilen kann, gibt es keine Garantie, dass es nie NULL sein wird.

Aber das heißt nicht kann NULL sein. Nur dass die Analyse, die erforderlich ist, um zu beweisen, dass es sicher ist, für PREfast zu komplex ist.

Möglicherweise können Sie die Microsoft-spezifische Erweiterung __assume verwenden, um dem Compiler mitzuteilen, dass diese Warnung nicht ausgegeben werden soll, aber eine bessere Lösung besteht darin, die Warnung zu verlassen. Jedes Mal, wenn Sie mit/compile kompilieren (was nicht bei jeder Kompilierung erforderlich sein muss), sollten Sie sicherstellen, dass die Warnungen, die auftauchen, immer noch falsch sind.

Wenn Sie verwenden behaupten richtig (logische Fehler bei der Programmierung zu fangen, gegen Situationen Bewachung dass nicht passieren, dann habe ich kein Problem mit Ihrem Code zu sehen, oder die Warnung mit verlassen. Code Hinzufügen ein Problem zu handhaben, dass nie auftreten ist nur sinnlos.Sie fügen mehr Code und mehr Komplexität ohne Grund (wenn es nie auftreten kann, dann haben Sie keine Möglichkeit, davon zu erholen, weil Sie absolut keine Ahnung haben, in welchem ​​Zustand das Programm sein wird Alles, was Sie wissen, ist, dass es einen Codepfad eingegeben hat, den Sie für unmöglich hielten.

Wenn Sie jedoch Ihre Assert als tatsächliche Fehlerbehandlung verwenden (der Wert kann in Ausnahmefällen NULL sein, Sie erwarten nur, dass es nicht passieren wird), dann ist es ein Fehler in Ihrem Code. Dann ist eine ordnungsgemäße Fehlerbehandlung (normalerweise Ausnahmen) erforderlich.

Niemals jemals für Probleme, die möglich sind. Verwenden Sie sie, um zu verifizieren, dass die unmöglich nicht geschieht. Und wenn/analyse dir Warnungen gibt, sieh sie dir an. Wenn es falsch positiv ist, ignoriere es (unterdrücke es nicht, denn während es heute falsch positiv ist, kann der Code, den du morgen eincheckst, möglicherweise ein echtes Problem werden).

Answer 4

Denken Sie daran, ASSERT() geht weg in einem Einzelhandel bauen, so dass die Warnung C6011 in Ihrem Code oben absolut korrekt ist: Sie müssen überprüfen, dass pBytes nicht Null ist, sowie die ASSERT(). Das ASSERT() wirft Ihre App einfach in einen Debugger, wenn diese Bedingung in einem Debug-Fehler erfüllt ist.

Ich arbeite sehr viel an/analysieren und PREfast, also wenn Sie andere Fragen haben, fühlen Sie sich bitte, lassen Sie es mich wissen.

Answer 5

Mein Co-Autor David LeBlanc würde mir sagen, dieser Code ist sowieso gebrochen, Sie verwenden C++ vorausgesetzt, sollten Sie einen Verweis eher als ein Zeiger und ein ref kann nicht NULL verwenden :)

Answer 6

Zunächst muss Ihre Assertion-Anweisung garantieren, die Anwendung zu werfen oder zu beenden. Nach einigen Experimenten, die ich in diesem Fall gefunden habe/analyze ignoriert alle Implementierungen entweder in Template-Funktionen, Inline-Funktionen oder normalen Funktionen. Sie müssen stattdessen Makros und die Do {} while (0) Trick, mit Inline-Unterdrückung von

Wenn Sie die Definition von ATLENSURE() Microsoft verwenden __analyse_assume() in ihrem Makro, sie haben auch mehrere Absätze von sehr Gute Dokumentation darüber, warum und wie sie ATL migrieren, um dieses Makro zu verwenden.

Als Beispiel habe ich die CPPUNIT_ASSERT-Makros auf die gleiche Weise modifiziert, um Tausende von Warnungen in unseren Unit-Tests zu bereinigen.

#define CPPUNIT_ASSERT(condition)                 \ 
do { (CPPUNIT_NS::Asserter::failIf(!(condition),            \ 
            CPPUNIT_NS::Message("assertion failed"),       \ 
            CPPUNIT_SOURCELINE())); __analysis_assume(!!(condition));  \ 
            __pragma(warning(push))           \ 
            __pragma(warning(disable: 4127))        \ 
            } while(0)               \ 
            __pragma(warning(pop))