Ein Tag vom PVS-Studio User Support

Wir freuen uns über Chats zur Codequalität. Unsere Kunden, Studenten und andere Benutzer aus allen Ecken des Internets schreiben uns. Unabhängig von Land, Zeitzone oder Sprache. Nun, Sprache sprechen, nicht programmieren. Unter den Programmiersprachen sind wir bisher an einem begrenzten Satz interessiert. Im Moment ist es C, C ++, C # und Java. Kommunikation bietet viele Vorteile. Wir setzen die Vorschläge einiger Benutzer sofort um, da sie wirklich nützlich sind. Oft helfen wir nur bei einem Projekt, indem wir die Warnungen des Analysators erklären, die letztendlich zu Fehlern führen. Dieser Hinweis handelt von einem solchen Fall.

Über den Analysator

PVS-Studio ist ein Tool zum Erkennen von Fehlern und potenziellen Schwachstellen im Quellcode von Programmen, die in C, C ++, C # und Java geschrieben wurden. Es funktioniert in Windows-, Linux- und MacOS-Umgebungen.

Es gibt drei Feedback-Formulare, mit denen Sie uns kontaktieren können:

1. Feedback
2. Testanfrage
3. Preisanfrage

Donnerstag Nacht

Ein aktiver Benutzer, der den Analysator in seinem Code ausprobiert hat, hat aktiv falsche Warnungen gesendet. Bevor ich antworten konnte, gab es bereits 3 E-Mails. Es war das Ende des Arbeitstages und ich war müde (ich sprach über die Frage der Zuverlässigkeit der manuellen Codeüberprüfung). Unser Team bereitete sich aktiv auf eine hochkarätige Veröffentlichung vor, die einige Tage entfernt war.

Ich beschloss, am Freitag oder sogar in der nächsten Woche zu antworten:

Hallo Konstantin

Wir werden Ihre Warnungen überprüfen. Nächste Woche werde ich verdächtige Orte kommentieren :-)

In diesem Hinweis geht es um die Wirksamkeit der statischen Code-Analyse. Die manuelle Codeüberprüfung ist in vielen Fällen der automatischen Überprüfung unterlegen, insbesondere am Ende des Tages.

Mit Erlaubnis des Benutzers werde ich Ihnen unsere Mails zitieren:

E-Mail 1

Falsch positive V712-Warnungen:

uint32_t StartUpCounter = 0, HSEStatus = 0; RCC->CR |= ((uint32_t)RCC_CR_HSEON); /* Wait till HSE is ready and if Time out is reached exit */ { HSEStatus = RCC->CR & RCC_CR_HSERDY; StartUpCounter++; } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT)); // V712... 

E-Mail 2

V715 falsch positiv für dasselbe Fragment:

 { // V715 ... lpmode.cpp 356 HSEStatus = RCC->CR & RCC_CR_HSERDY; StartUpCounter++; } while((HSEStatus == 0) && (StartUpCounter != HSE_STARTUP_TIMEOUT)); 

E-Mail 3

Heilige Katzen, so ein Spukplatz! Der Analysator beschwert sich über dasselbe Fragment (siehe Code aus den vorherigen E-Mails):

V560 Ein Teil des bedingten Ausdrucks ist immer wahr: (StartUpCounter! = ((Uint16_t) 0x5000)). lpmode.cpp 356

V776 Potenziell Endlosschleife. Die Variable in der Schleifenausgangsbedingung 'HSEStatus == 0' ändert ihren Wert zwischen den Iterationen nicht. lpmode.cpp 356

Vielleicht bekomme ich nichts? Aber in der Praxis funktioniert alles und wenn der Quarz nicht startet, verlassen wir dieses Fragment beim Timeout ;-)

E-Mail 4 (Antwort)

Hallo Konstantin

Wir werden Ihre Warnungen überprüfen. Nächste Woche werde ich verdächtige Orte kommentieren :-)

E-Mail 5

Verdammt! Erst nach Ihrer E-Mail habe ich festgestellt, dass die Aussage "do" fehlt ... Endlich sind alle in einen Groove geraten! Scheint, als hätte ich meine Augenschärfe komplett verloren%)

mache {...} while (...);

Fazit

Wie Sie vielleicht bemerkt haben, gab es 4 Analysatorwarnungen für dasselbe Fragment, aber es dauerte immer noch einige Zeit, um den Benutzer von einem Fehler zu überzeugen. In einer solchen Situation hätte eine manuelle Überprüfung nicht einmal eine Chance.

Eine ähnliche Geschichte mit Happy End: " Wie sich PVS-Studio als aufmerksamer als dreieinhalb Programmierer erwies "

Verwenden Sie in Ihrem Projekt statische Analysegeräte. Sie ersetzen die Codeüberprüfung nicht durch Kollegen, sondern unterstützen die Codequalitätskontrolle.