Was ist Misra und wie man es kocht

Vielleicht hat jeder Entwickler von Mikrocontroller-Software von speziellen Codierungsstandards gehört, um die Codesicherheit und Portabilität zu verbessern. Einer dieser Standards ist MISRA. In diesem Artikel werden wir uns genauer mit diesem Standard, seinem Konzept und seiner Verwendung in Ihren Projekten befassen.

Viele unserer Leser haben gehört, dass PVS-Studio die Klassifizierung seiner Warnungen nach dem MISRA-Standard unterstützt. Derzeit deckt PVS-Studio mehr als 100 MISRA C-Regeln ab: 2012 und MISRA C ++: 2008.

Dieser Artikel zielt darauf ab, drei Fliegen mit einer Klappe zu schlagen:

1. Sagen Sie, was MISRA für diejenigen ist, die mit diesem Standard noch nicht vertraut sind.
2. Erinnern Sie die Welt der eingebetteten Entwicklung daran, was wir tun können.
3. Helfen Sie neuen Mitarbeitern unseres Unternehmens, die künftig auch unseren MISRA-Analysator weiterentwickeln, sich mit ihm vertraut zu machen.

Ich hoffe ich kann es interessant machen. Also los geht's!

Die Geschichte der Misra

Die Geschichte von MISRA begann vor langer Zeit. Damals, in den frühen neunziger Jahren, finanzierte das britische Regierungsprogramm "Safe IT" verschiedene Projekte, die in irgendeiner Weise mit der Sicherheit elektronischer Systeme zu tun hatten. Das MISRA-Projekt (Motor Industry Software Reliability Association) wurde gegründet, um einen Leitfaden für die Entwicklung von Software für Mikrocontroller in Bodenfahrzeugen zu erstellen - hauptsächlich in Autos.

Das vom Staat finanzierte MISRA-Team nahm die Arbeiten auf und veröffentlichte im November 1994 seinen ersten Leitfaden: " Entwicklungsrichtlinien für fahrzeugbasierte Software ". Dieser Leitfaden war noch nicht an eine bestimmte Sprache gebunden, aber ich muss zugeben, dass die Arbeit beeindruckend war und wahrscheinlich alle denkbaren Aspekte der Entwicklung eingebetteter Software betraf. Übrigens haben die Entwickler dieses Handbuchs kürzlich das 25-jährige Jubiläum eines für sie so wichtigen Termins gefeiert .

Als die Finanzierung durch den Staat beendet war, beschlossen die MISRA-Mitglieder, weiterhin informell zusammenzuarbeiten, was bis heute so bleibt. Generell ist MISRA (als Organisation) eine Community von Stakeholdern aus verschiedenen Auto- und Flugzeugindustrien. Nun sind diese Parteien:

• Bentley-Kraftfahrzeuge
• Ford Motor Company
• Jaguar Land Rover
• Delphi-Dieselsysteme
• HORIBA MIRA
• Protean elektrisch
• Ingenieurdienstleistungen von Visteon
• Die Universität von Leeds
• Ricardo uk
• ZF TRW

Sehr starke Marktteilnehmer, nicht wahr? Es ist nicht überraschend, dass ihr erster sprachbezogener Standard, MISRA C, unter Entwicklern kritischer eingebetteter Systeme zum Alltag geworden ist. Wenig später erschien MISRA C ++. Allmählich wurden Versionen der Standards aktualisiert und verfeinert, um die neuen Funktionen der Sprachen abzudecken. Derzeit sind die aktuellen Versionen MISRA C: 2012 und MISRA C ++: 2008.

Hauptkonzept und Beispiele für Regeln

MISRA zeichnet sich durch eine unglaubliche Liebe zum Detail und äußerste Sorgfalt bei der Gewährleistung von Sicherheit und Schutz aus. Die Autoren haben nicht nur alle C- und C ++ - Mängel an einem Ort gesammelt (wie zum Beispiel die Autoren von CERT), sondern auch die internationalen Standards dieser Sprachen sorgfältig ausgearbeitet und alle Arten von Fehlern aufgeschrieben. Anschließend fügten sie Regeln zur Codelesbarkeit hinzu, um den bereinigten Code vor einem neuen Fehler zu schützen.

Sehen wir uns ein paar Regeln an, die dem Standard entnommen sind, um das Ausmaß des Ernstes zu verstehen.

Einerseits gibt es anständige, lohnende Regeln, die immer befolgt werden müssen, egal für was Ihr Projekt ist. Zum größten Teil sollen sie undefiniertes / nicht angegebenes / implementierungsdefiniertes Verhalten beseitigen. Zum Beispiel:

• Verwenden Sie nicht den Wert einer nicht initialisierten Variablen
• Verwenden Sie den Zeiger nicht auf DATEI, nachdem der Stream geschlossen wurde
• Alle nicht leeren Funktionen sollten einen Wert zurückgeben
• Schleifenzähler dürfen nicht vom Typ Gleitkomma sein
• und andere.

Auf der anderen Seite gibt es Regeln, deren Nutzen nicht schwer zu ermitteln ist, die jedoch (aus Sicht gewöhnlicher Projekte) gelegentlich verletzt werden können:

• Verwenden Sie nicht goto und longjmp
• Jeder Schalter sollte mit der Standardbezeichnung enden
• Schreiben Sie keinen unerreichbaren Code
• Verwenden Sie keine variablen Funktionen
• Verwenden Sie keine Adressarithmetik (außer [] und ++ )
• ...

Solche Regeln sind auch nicht schlecht und zusammen mit den vorherigen erhöhen sie die Sicherheit bereits spürbar. Aber reicht dies für hochzuverlässige eingebettete Systeme aus? Sie werden nicht nur in der Automobilindustrie, sondern auch in der Luftfahrt-, Raumfahrt-, Militär- und Medizinindustrie eingesetzt.

Wir wollen nicht, dass ein Röntgengerät aufgrund eines Softwarefehlers Patienten mit einer Dosis von 20.000 Rad bestrahlt , daher reichen die üblichen "Alltagsregeln" nicht aus. Bei Menschenleben und viel Geld ist Sorgfalt unabdingbar. Hier kommen die restlichen MISRA-Regeln ins Spiel:

• Das Suffix 'L' im Literal muss immer ein Großbuchstabe sein (der Kleinbuchstabe 'l' kann mit 1 verwechselt werden)
• Verwenden Sie nicht den "Komma" -Operator (dies erhöht die Wahrscheinlichkeit, einen Fehler zu machen)
• Keine Rekursion verwenden (ein kleiner Mikrocontroller-Stack kann leicht überlaufen)
• Die Hauptteile der Anweisungen, falls andernfalls für while- do- switch geschweifte Klammern verwendet werden müssen (möglicherweise können Sie einen Fehler machen, wenn der Code falsch ausgerichtet ist )
• Verwenden Sie keinen dynamischen Speicher (da die Gefahr besteht, dass dieser nicht vom Heap freigegeben wird, insbesondere in Mikrocontrollern).
• ... und viele, viele dieser Regeln.

Es kommt häufig vor, dass Menschen, die MISRA zum ersten Mal begegnen, den Eindruck haben, dass der Zweck des Standards darin besteht, "dies und das zu verbieten". In der Tat ist es so, aber nur zu einem gewissen Grad.

Einerseits hat der Standard viele solcher Regeln, aber er soll nicht alles verbieten, andererseits listet er alle Möglichkeiten auf, die Codesicherheit irgendwie zu verletzen. Bei den meisten Regeln entscheiden Sie selbst, ob Sie sie befolgen müssen oder nicht. Ich werde diesen Fall näher erläutern.

In MISRA C sind die Regeln in drei Hauptkategorien unterteilt: Obligatorisch, Erforderlich und Beratung. Obligatorisch sind Regeln, die unter keinem Vorwand verletzt werden dürfen. Dieser Abschnitt enthält beispielsweise die Regel: "Verwenden Sie nicht den Wert einer nicht initiierten Variablen." Die vorgeschriebenen Regeln sind weniger streng: Sie sehen die Möglichkeit der Ablehnung vor, jedoch nur, wenn diese Abweichungen sorgfältig dokumentiert und schriftlich begründet werden. Der Rest der Regeln fällt in die Kategorie Advisory, die nicht obligatorisch sind.

MISRA C ++ weist einige Unterschiede auf: Es gibt keine obligatorische Kategorie, und die meisten Regeln gehören zur Kategorie Erforderlich. Daher haben Sie das Recht, gegen eine Regel zu verstoßen. Vergessen Sie jedoch nicht, alle Abweichungen zu kommentieren. Es gibt auch die Dokumentenkategorie - dies sind verbindliche Regeln (Abweichungen sind nicht zulässig) im Zusammenhang mit allgemeinen Vorgehensweisen wie "Jede Verwendung des Assemblers muss dokumentiert werden" oder "Eine enthaltene Bibliothek muss MISRA C ++ entsprechen".

Andere Probleme

Tatsächlich handelt es sich bei MISRA nicht nur um ein Regelwerk. Tatsächlich ist es eine Richtlinie zum Schreiben von sicherem Code für Mikrocontroller, und es steckt voller Extras. Schauen wir sie uns genauer an.

Zunächst enthält der Standard eine ziemlich gründliche Beschreibung der Hintergrundgeschichte: Warum der Standard erstellt wurde, warum C oder C ++ ausgewählt wurde, Vor- und Nachteile dieser Sprachen.

Wir alle kennen die Vorzüge dieser Sprachen sehr gut. Ebenso sind wir uns ihrer Mängel bewusst :) Hohe Komplexität, unvollständige Standardspezifikation und Syntax, die es ermöglichen, leicht einen Fehler zu machen und ihn dann für Ewigkeiten zu suchen - all dies kann nur erwähnt werden. Beispielsweise könnten Sie dies versehentlich schreiben:

for (int i = 0; i < n; ++i); { do_something(); } 

Immerhin besteht die Möglichkeit, dass eine Person kein zusätzliches Semikolon bemerkt, oder? Eine andere Möglichkeit besteht darin, Code wie folgt zu schreiben:

 void SpendTime(bool doWantToKillPeople) { if (doWantToKillPeople = true) { StartNuclearWar(); } else { PlayComputerGames(); } } 

Es ist gut, dass sowohl der erste als auch der zweite Fall leicht von den Regeln MISRA (1 - MISRA C: 13.4 / MISRA C ++: 6.2.1; 2 - MISRA C: 13.4 / MISRA C ++: 6.2.1) erfasst werden können.

Der Standard enthält sowohl eine Beschreibung der Probleme als auch Tipps dazu, was man wissen muss, bevor man eine bestimmte Aufgabe übernimmt: wie man den Entwicklungsprozess gemäß MISRA einrichtet; Verwendung von statischen Analysegeräten zur Überprüfung des Codes auf Konformität; Welche Dokumente muss man pflegen, wie füllt man sie aus und so weiter.

Die Anhänge am Ende enthalten außerdem: eine kurze Liste und eine Zusammenfassung der Regeln, eine kleine Liste von C / C ++ - Schwachstellen, ein Beispiel für eine Dokumentation zu Regelabweichungen und einige Checklisten, die dazu beitragen, all diese Bürokratie zu beseitigen.

Wie Sie sehen, handelt es sich bei MISRA nicht nur um ein Regelwerk, sondern um eine fast vollständige Infrastruktur zum Schreiben von sicherem Code für eingebettete Systeme.

Verwendung in Ihren Projekten

Stellen Sie sich die Szene vor: Sie werden ein Programm für ein so notwendiges und verantwortungsbewusstes Embedded-System schreiben. Oder Sie haben bereits ein Programm, müssen es aber nach MISRA "portieren". Wie überprüfen Sie Ihren Code auf Übereinstimmung mit dem Standard? Müssen Sie es wirklich manuell machen?

Die manuelle Codeüberprüfung ist eine schwierige und möglicherweise sogar unmögliche Aufgabe. Jeder Rezensent muss nicht nur jede Codezeile sorgfältig durchsehen, sondern auch den Standard fast auswendig können. Verrückt!

Daher raten die MISRA-Entwickler selbst zur statischen Analyse, um Ihren Code zu testen. Schließlich ist die statische Analyse ein automatisierter Prozess der Codeüberprüfung. Sie führen den Analyzer einfach mit Ihrem Programm aus und in wenigen Minuten erhalten Sie einen Bericht über mögliche Verstöße gegen den Standard. Das ist was du brauchst, nicht wahr? Sie müssen lediglich das Protokoll überprüfen und die Warnungen korrigieren.

Die nächste Frage ist - ab wann sollten wir MISRA einsetzen? Die Antwort ist einfach: Je früher, desto besser. Idealerweise - bevor Sie überhaupt mit dem Schreiben von Code beginnen, da MISRA davon ausgeht, dass Sie den Standard für den gesamten Lebenszyklus Ihres Codes einhalten.

Nun, es ist nicht immer möglich, von Anfang an nach MISRA zu schreiben. Beispielsweise ist es häufig so, dass das Projekt bereits teilweise oder vollständig umgesetzt wurde, der Kunde jedoch später wünschte, dass das Projekt dem Standard entspricht. In diesem Fall müssen Sie den vorhandenen Code gründlich überarbeiten.

Hier taucht die Falle auf. Ich würde sogar sagen, dass ein Unterwasser-Felsbrocken auftaucht. Was passiert, wenn Sie einen statischen Analysator nehmen und das "normale" Projekt überprüfen, um den MISRA-Standard zu erfüllen? Spoiler: Sie können Angst haben.

Richtig, das Beispiel auf dem Bild ist übertrieben. Es zeigt das Ergebnis der Überprüfung eines ziemlich großen Projekts, das eigentlich nicht für die Arbeit an Mikrocontrollern gedacht war. Wenn Sie jedoch bereits vorhandenen Code überprüfen, erhalten Sie möglicherweise eine, zwei, drei oder sogar zehntausend Analysatorwarnungen. Neue Warnungen, die für neuen oder geänderten Code ausgegeben werden, gehen einfach in dieser großen Reihe von Warnungen verloren.

Was können Sie dagegen tun? Müssen Sie wirklich alle Aufgaben verschieben und alle Anstrengungen unternehmen, um alte Warnungen zu beheben?

Als Entwickler des statischen Analysators wissen wir, dass nach der Überprüfung so viele Warnungen angezeigt werden. Aus diesem Grund haben wir eine Lösung entwickelt, mit der Sie den Analysator sofort verwenden können, ohne die Arbeit zu unterbrechen. Diese Lösung heißt "Basis unterdrücken".

Unterdrückungsbasen stellen den PVS-Studio-Mechanismus dar, mit dem Sie Analysatormeldungen massiv unterdrücken können. Wenn Sie ein Projekt zum ersten Mal überprüfen und mehrere Tausend Warnungen erhalten, müssen Sie sie nur in eine Unterdrückungsbasis einfügen. Beim nächsten Durchlauf erhalten Sie keine Warnungen.

Auf diese Weise können Sie den Code wie gewohnt weiter schreiben und ändern. Dabei erhalten Sie nur Meldungen zu Fehlern, die gerade im Projekt aufgetreten sind. So können Sie hier und jetzt den größten Nutzen aus dem Analysegerät ziehen, ohne von alten Fehlern abgelenkt zu werden. Ein paar Klicks - und der Analysator wird in Ihre Entwicklung übernommen! Die ausführlichen Anweisungen dazu finden Sie hier .

Vielleicht fragen Sie sich: „Warten Sie, was ist mit den versteckten Warnungen?“ Die Antwort ist ganz einfach: Vergessen Sie sie nicht und beheben Sie sie in einfachen Schritten. Beispielsweise können Sie die Unterdrückungsbasis in das Versionskontrollsystem laden und nur solche Festschreibungen zulassen, die die Anzahl der Warnungen nicht erhöhen. So schleift Ihr „Unterwasser-Felsblock“ früher oder später spurlos ab.

Okay, der Analyzer ist nun erfolgreich übernommen und wir können fortfahren. Was ist als nächstes zu tun? Die Antwort liegt auf der Hand - arbeiten Sie mit dem Code! Aber was braucht es, um die Konformität mit der Norm zu erklären? Wie beweisen Sie, dass Ihr Projekt MISRA entspricht?

Tatsächlich gibt es kein spezielles "Zertifikat", dass Ihr Code MISRA entspricht. Standardmäßig sollte das Compliance-Tracking von zwei Parteien durchgeführt werden: dem Software-Kunden und dem Software-Anbieter. Der Anbieter entwickelt eine Software, die dem Standard entspricht und die erforderlichen Dokumente ausfüllt. Der Kunde muss seinerseits sicherstellen, dass die Daten aus diesen Dokumenten wahr sind.

Wenn Sie Software für sich selbst entwickeln, liegt die Verantwortung für die Einhaltung des Standards nur bei Ihnen :)

Um die Konformität Ihres Projekts nachzuweisen, benötigen Sie im Allgemeinen Belege. Die Liste der Dokumente, die Projektentwickler vorbereiten sollten, kann variieren, aber MISRA bietet einige als Referenz. Schauen wir uns dieses Set genauer an.

Sie benötigen diese Dinge, um die Standardkonformität anzuwenden:

• Das Projekt selbst, dessen Code den obligatorischen und erforderlichen Regeln entspricht
• Führungsdurchsetzungsplan
• Dokumentation zu allen Compiler- und Static Analyzer-Warnungen
• Dokumentation für alle Abweichungen von den erforderlichen Regeln
• Richtlinien-Compliance-Zusammenfassung

Der erste ist ein Durchsetzungsplan. Dies ist Ihre wichtigste Tabelle und enthält Verweise auf alle anderen Dokumente. In der ersten Spalte finden Sie eine Liste der MISRA-Regeln. Im Übrigen wird vermerkt, ob Abweichungen von diesen Regeln aufgetreten sind. Diese Tabelle sieht ungefähr so ​​aus:

Der Standard empfiehlt, Ihr Projekt mit mehreren Compilern zu erstellen und zwei oder mehr statische Analysatoren zu verwenden, um Ihren Code auf Kompatibilität zu testen. Wenn der Compiler oder Analyzer eine regelbezogene Warnung ausgibt, sollten Sie diese in der Tabelle notieren und die folgenden Punkte dokumentieren: Warum kann die Warnung nicht behoben werden, ob sie falsch ist oder nicht usw.

Wenn eine der Regeln nicht von einem statischen Analysegerät überprüft werden kann, müssen Sie eine manuelle Codeüberprüfung durchführen. Dieses Verfahren muss ebenfalls dokumentiert werden. Anschließend sollte ein Link zu dieser Dokumentation zum Compliance-Plan hinzugefügt werden.

Wenn sich der Compiler oder der statische Analysator als richtig herausstellt oder wenn während des Codeüberprüfungsprozesses gültige Regelverstöße vorliegen, müssen Sie diese entweder korrigieren oder dokumentieren. Nochmals, indem Sie den Link zur Dokumentation in der Tabelle anhängen.

Ein Compliance-Plan ist daher ein Dokument, das eine Dokumentation für jede in Ihrem Code festgestellte Abweichung enthält.

Lassen Sie uns kurz darauf eingehen, Abweichungen von den Regeln direkt zu dokumentieren. Wie bereits erwähnt, ist eine solche Dokumentation nur für erforderliche Regeln erforderlich, da obligatorische Regeln nicht verletzt werden können und Beratungsregeln ohne Dokumentation verletzt werden können.

Wenn Sie von der Regel abweichen möchten, sollte die Dokumentation Folgendes enthalten:

• Die Nummer der Regel, gegen die verstoßen wurde
• Der genaue Ort der Abweichung
• Die Gültigkeit der Abweichung
• Beweis, dass die Abweichung die Sicherheit nicht beeinträchtigt
• Mögliche Folgen für den Benutzer

Wie Sie sehen, werden Sie sich bei einem solchen Dokumentationsansatz ernsthaft fragen, ob sich der Verstoß lohnt. Dies geschah speziell, um nicht das Verlangen zu verspüren, die erforderlichen Regeln zu verletzen :)

Nun zur Zusammenfassung der Einhaltung der Regeln. Dieses Papier ist vielleicht am einfachsten zu füllen:

Die mittlere Spalte wird gefüllt, bevor Sie mit der Arbeit am Code beginnen, und die rechte - nachdem Ihr Projekt fertig ist.

Hier ist eine vernünftige Frage: Warum sollten die Kategorien von Regeln spezifiziert werden, wenn sie bereits in der Norm selbst spezifiziert sind? Tatsache ist, dass der Standard es erlaubt, eine Regel in eine strengere Kategorie zu "befördern". Zum Beispiel könnte ein Kunde Sie auffordern, eine Beratungsregel zu kategorisieren. Eine solche "Promotion" sollte durchgeführt werden, bevor mit dem Code gearbeitet wird, und die Zusammenfassung der Einhaltung der Regeln ermöglicht es Ihnen, dies explizit zu vermerken.

Bei der letzten Spalte ist es ganz einfach: Sie müssen nur notieren, ob die Regel verwendet wird, und wenn ja, ob es Abweichungen davon gibt.

Diese ganze Tabelle wird benötigt, damit Sie schnell sehen können, welche Prioritäten Regeln haben und ob der Code mit ihnen übereinstimmt. Wenn Sie plötzlich die genaue Ursache der Abweichung erfahren möchten, können Sie sich jederzeit an den Compliance-Plan wenden und die erforderliche Dokumentation finden.

Sie haben den Code also sorgfältig gemäß den MISRA-Regeln geschrieben. Sie haben einen Compliance-Plan erstellt und alles dokumentiert, was dokumentiert werden konnte, und Sie haben Ihre Compliance-Lebensläufe ausgefüllt. Wenn dies tatsächlich der Fall ist, dann haben Sie einen sehr sauberen, sehr lesbaren und sehr zuverlässigen Code, den Sie jetzt hassen :)

Wo wird dein Programm jetzt leben? In einem MRT-Gerät? In einem gewöhnlichen Geschwindigkeitssensor oder in der Steuerung eines Weltraumsatelliten? Ja, Sie haben einen ernsthaften bürokratischen Weg durchlaufen, aber das ist keine große Sache. Wenn es um echte Menschenleben geht, muss man immer gewissenhaft sein.

Wenn Sie es geschafft haben, das siegreiche Ende zu erreichen, gratuliere ich Ihnen ganz herzlich: Sie schreiben hochwertigen, sicheren Code. Danke schön

Die Zukunft der Standards

Zum Finale möchte ich auf die Zukunft der Standards eingehen.

Jetzt lebt und entwickelt sich Misra. Beispiel: "Die dritte Ausgabe von MISRA C: 2012 (Erste Überarbeitung)" ist eine überarbeitete und um neue Regeln erweiterte Ausgabe, die Anfang 2019 angekündigt wurde. Gleichzeitig wird die bevorstehende Veröffentlichung von "MISRA C: 2012, Änderung 2 - C11" veröffentlicht Core “, ein überarbeiteter Standard des Jahres 2012, wurde angekündigt. Dieses Dokument wird Regeln enthalten, die zum ersten Mal die C-Sprachversionen von 2011 und 2018 abdecken.

Auch MISRA C ++ entwickelt sich weiter. Wie Sie wissen, stammt der letzte Standard von MISRA C ++ aus dem Jahr 2008, daher ist die älteste Version der Sprache, die es abdeckt, C ++ 03. Aus diesem Grund gibt es einen anderen Standard, der MISRA ähnelt und AUTOSAR C ++ heißt. Es war ursprünglich als Fortsetzung von MISRA C ++ gedacht und sollte spätere Versionen der Sprache abdecken. Im Gegensatz zu seinem Mastermind wird AUTOSAR C ++ zweimal im Jahr aktualisiert und unterstützt derzeit C ++ 14. Neue Updates für C ++ 17 und C ++ 20 stehen noch aus.

Warum habe ich über einen anderen Standard gesprochen? Fakt ist, dass beide Organisationen vor knapp einem Jahr angekündigt haben, ihre Standards in einem zusammenzuführen. MISRA C ++ und AUTOSAR C ++ werden zu einem einzigen Standard und von nun an gemeinsam weiterentwickelt. Ich denke, das sind großartige Neuigkeiten für Entwickler, die in C ++ für Mikrocontroller schreiben, und nicht weniger großartige Neuigkeiten für Entwickler von statischen Analysegeräten. Es gibt noch viel mehr zu tun! :)

Fazit

Heute haben Sie hoffentlich viel über MISRA gelernt: Lesen Sie die Geschichte seiner Entstehung, studieren Sie die Beispiele für Regeln und Konzepte des Standards, überlegen Sie sich alles, was Sie für die Verwendung von MISRA in Ihren Projekten benötigen, und werfen Sie einen Blick auf die Zukunft. Ich hoffe, Sie verstehen jetzt besser, was MISRA ist und wie man es kocht!

In der alten Tradition werde ich hier einen Link zu unserem statischen Analysator PVS-Studio hinterlassen. Es kann nicht nur Abweichungen vom MISRA-Standard feststellen, sondern auch eine Vielzahl von Fehlern und Schwachstellen. Wenn Sie PVS-Studio selbst ausprobieren möchten, laden Sie die Demoversion herunter und überprüfen Sie Ihr Projekt.

Hier endet mein Artikel. Ich wünsche allen Lesern ein frohes Weihnachtsfest und einen guten Rutsch ins Neue Jahr!