PVS-Studio 7.14:intermodulare Analyse in C++ und Plugin für JetBrains CLion

PVS-Studio 7.14:intermodulare Analyse in C++ und Plugin für JetBrains CLion

Das PVS-Studio-Team erhöht die Anzahl der Diagnosen mit jeder neuen Version. Außerdem verbessern wir die Infrastruktur des Analysators. Dieses Mal haben wir das Plugin für JetBrains CLion hinzugefügt. Darüber hinaus haben wir die intermodulare Analyse von C++-Projekten eingeführt und den C#-Analysekern beschleunigt.

Integration von PVS-Studio in JetBrains CLion

Wir haben ein benutzerfreundliches Plugin eingeführt, das bei der Verwendung von PVS-Studio in JetBrains CLion hilft. Besuchen Sie unseren Blog, um mehr über Schwierigkeiten zu erfahren, auf die wir bei der Entwicklung des CLion-Plug-ins gestoßen sind. Hier können Sie die Liste der JetBrains-IDEs anzeigen, die PVS-Studio bereits unterstützt.

Da wir das Plugin zum ersten Mal für CLion veröffentlichen, können bei der Verwendung des Plugins einige Unannehmlichkeiten oder Fehler auftreten. Zögern Sie in diesem Fall nicht, uns zu schreiben. Wir versuchen zu helfen, Ratschläge zu geben oder Mängel zu beheben. Vielen Dank im Voraus.

Intermodulare Analyse von C- und C++-Projekten

Der PVS-Studio C++ Analyzer unterstützt jetzt die intermodulare Analyse. In diesem Modus berücksichtigt der Analysator beim Analysieren des Codes die Ergebnisse von Methodenaufrufen, die in anderen Übersetzungseinheiten deklariert sind. Wir haben auch eine intermodulare Analyse im C#-Analyzer (auf Projektebene) und im Java-Analyzer (auf Paketebene). Im C++-Analyzer ist dieser Modus standardmäßig deaktiviert, da er die Analysegeschwindigkeit verlangsamen kann. Erfahren Sie mehr über die intermodulare Analyse und ihre Implementierungsfunktionen in unserem Blog.

C#-Analyzer beschleunigen

Jetzt prüft der C#-Analyzer große Projekte (mehr als 10.000 Quelldateien) doppelt so schnell. Darüber hinaus nutzt der C#-Analyzer Mehrkernprozessoren viel effizienter. Sehen Sie sich unseren Blog an, um Techniken zu sehen, mit denen wir den C#-Analyzer beschleunigt haben. Diese Techniken können für andere Klassen von .NET-Anwendungen angewendet werden:

  • .NET-Anwendungsoptimierung:Einfache Bearbeitungen beschleunigten PVS-Studio und reduzierten den Speicherverbrauch um 70 %.
  • Optimierung von .NET-Anwendungen:ein großes Ergebnis kleiner Änderungen.

29 neue Diagnosen

Wie die folgende Liste zeigt, basieren die meisten Diagnosen, die wir derzeit implementieren, auf dem MISRA C-Standard. Wir haben uns auf die Unterstützung von MISRA C konzentriert, und jetzt deckt PVS-Studio 60 % des Standards ab. Bald wollen wir mindestens 80 % abdecken. Außerdem möchten wir die Unterstützung von Codierungsstandards aus der MISRA C Compliance einführen.

Darüber hinaus verbessern wir weiterhin die Analysefunktionen zur Identifizierung potenzieller Schwachstellen. Jetzt deckt PVS-Studio 6 von 10 Kategorien in OWASP Top 10 ab – der Liste der häufigsten und gefährlichsten Sicherheitsbedrohungen für Webanwendungen. In dieser Version haben wir Diagnosen für die Kategorien A5 Broken Access Control, A7 Cross-Site Scripting (XSS) und A8 Unsichere Deserialisierung hinzugefügt. In zukünftigen Versionen in diesem Jahr planen wir, die Abdeckung auf 9 Kategorien zu erhöhen.

  • V2015. Ein in einem inneren Gültigkeitsbereich deklarierter Bezeichner sollte einen Bezeichner in einem äußeren Gültigkeitsbereich nicht verbergen.
  • V2016. Erwägen Sie, den Funktionsaufruf zu untersuchen. Die Funktion wurde als gefährlich gekennzeichnet.
  • V2584. MISRA. Der in der Bedingung verwendete Ausdruck sollte den wesentlichen booleschen Typ haben.
  • V2585. MISRA. Umwandlungen zwischen einem void-Zeiger und einem arithmetischen Typ sollten nicht durchgeführt werden.
  • V2586. MISRA. Flexible Array-Mitglieder sollten nicht deklariert werden.
  • V2587. MISRA. Die Zeichenfolgen „//“ und „/*“ sollten nicht in Kommentaren vorkommen.
  • V2588. MISRA. Alle dynamisch zugewiesenen Speicher oder Ressourcen sollten explizit freigegeben werden.
  • V2589. MISRA. Umwandlungen zwischen einem Zeiger und einem nicht ganzzahligen arithmetischen Typ sollten nicht durchgeführt werden.
  • V2590. MISRA. Zwischen Zeiger auf Funktion und anderen Typen sollten keine Konvertierungen durchgeführt werden.
  • V2591. MISRA. Bitfelder sollten nur mit explizit signiertem oder unsigned Integer-Typ deklariert werden.
  • V2592. MISRA. Ein in einem inneren Gültigkeitsbereich deklarierter Bezeichner sollte einen Bezeichner in einem äußeren Gültigkeitsbereich nicht verbergen.
  • V2593. MISRA. Einzelbit-Bitfelder sollten nicht als vorzeichenbehafteter Typ deklariert werden.
  • V2594. MISRA. Steuerausdrücke sollten nicht unveränderlich sein.
  • V2595. MISRA. Die Array-Größe sollte explizit angegeben werden, wenn die Array-Deklaration eine bestimmte Initialisierung verwendet.
  • V2596. MISRA. Der Wert eines zusammengesetzten Ausdrucks sollte keinem Objekt mit einem breiteren essentiellen Typ zugewiesen werden.
  • V2597. MISRA. Cast sollte Zeiger auf Funktion nicht in einen anderen Zeigertyp umwandeln.
  • V2598. MISRA. Array-Typen mit variabler Länge sind nicht zulässig.
  • V2599. MISRA. Die Standard-Signalverarbeitungsfunktionen sollten nicht verwendet werden.
  • V2600. MISRA. Die Standard-Ein-/Ausgabefunktionen sollten nicht verwendet werden.
  • V2601. MISRA. Funktionen sollten in Prototypform mit benannten Parametern deklariert werden.
  • V2602. MISRA. Oktale und hexadezimale Escape-Sequenzen sollten beendet werden.
  • V2603. MISRA. Das Schlüsselwort „static“ darf nicht zwischen [] in der Deklaration eines Array-Parameters verwendet werden.
  • V3172. Die Anweisung „if/if-else/for/while/foreach“ und der Codeblock danach sind nicht verwandt. Überprüfen Sie die Logik des Programms.
  • V3552. AUTOSAR. Cast sollte einen Zeiger auf eine Funktion nicht in einen anderen Zeigertyp umwandeln, einschließlich eines Zeigers auf einen Funktionstyp.
  • V3553. AUTOSAR. Die Standard-Signalverarbeitungsfunktionen sollten nicht verwendet werden.
  • V3554. AUTOSAR. Die Standard-Ein-/Ausgabefunktionen sollten nicht verwendet werden.
  • V5609. OWASP. Mögliche Schwachstelle bei Pfaddurchquerung. Potenziell verfälschte Daten werden als Pfad verwendet.
  • V5610. OWASP. Mögliche XSS-Schwachstelle. Potenziell verdorbene Daten könnten verwendet werden, um ein bösartiges Skript auszuführen.
  • V5611. OWASP. Potenzielle Schwachstelle bei unsicherer Deserialisierung. Potenziell verfälschte Daten werden verwendet, um ein Objekt mithilfe der Deserialisierung zu erstellen.

Weitere Details

Das PVS-Studio-Plugin für SonarQube unterstützt SonarQube 8.9 LTS.

Jetzt können Sie im PVS-Studio C++ Analyzer Diagnoseregeln für einen bestimmten Zeilenbereich in der Quelldatei deaktivieren. Siehe den Abschnitt „Aktivieren und Deaktivieren bestimmter Diagnosen für einen Codeblock“ in der Dokumentation zur Unterdrückung von Fehlalarmen.

Einer unserer Benutzer hat einen Artikel über die Integration des PVS-Studio-Analyzers in uVision Keil geschrieben. PVS-Studio bietet eine solche Option nicht standardmäßig an. Aber wenn Sie etwas wollen, werden wir unser Bestes tun, um es umzusetzen :). Die Geschichte ist unterhaltsam geworden. Werfen Sie einen Blick darauf, auch wenn Sie uVision Keil nicht verwenden:Integration von PVS-Studio in uVision Keil. Hier ist ein Zitat aus dem Artikel:

Einige Artikel, die nach der vorherigen Version veröffentlicht wurden

  • Ein unerwarteter Artikel über unser Einhorn:Wer ist das Maskottchen von PVS-Studio?
  • Ein schöner Fehler in der Implementierung der String-Verkettungsfunktion.
  • Enumerationen in C#:versteckte Fallstricke.
  • OWASP, Schwachstellen und Taint-Analyse in PVS-Studio für C#. Rühren, aber nicht schütteln.
  • Statische Analyse schützt Ihren Code vor Zeitbomben.
  • PVS-Studio-Team:Der Wechsel zu Clang verbesserte die Leistung des C++-Analyzers von PVS-Studio