Mein Kollege hat kürzlich unser Programm in Windows kompiliert und einen Fehler dieser Art entdeckt:
%Vor%das aus irgendeinem Grund nicht in unseren ausführbaren Linux-Dateien abstürzte.
Keiner unserer Compiler gibt irgendeine Warnung aus, daher machen wir uns jetzt Sorgen, dass dieser Fehler im Code vorhanden sein könnte.
Obwohl wir grep für c_str() auftreten und eine visuelle Inspektion durchführen können, besteht die Möglichkeit, dass Sie auch Folgendes getan haben:
und darauf zugegriffen wie:
%Vor%anstelle von:
%Vor%was ist sicher (nicht wahr?)
Frage: Gibt es eine Möglichkeit, solche Fehler zu finden (vielleicht mithilfe des Compilers oder sogar einer Assertion)?
Ich muss sicher sein, dass, wenn der Autor von struct X get() zwischen Version 1 und 2 ändert, dass das Programm für den Fehler warnt
Sehen Sie sich die Lösung dieser Frage an, ich denke, sie macht etwas, wonach Sie suchen:
Es gibt Laufzeit-basierte Lösungen, die den zu überprüfenden Code instrumentieren ungültige Zeigerzugriffe. Ich habe bisher nur Schmutzfänger benutzt (was ist seit Version 4.0 in GCC integriert). Schmutzfänger versucht jeden zu verfolgen Zeiger (und Referenz) im Code und überprüft jeden Zugriff, wenn der Zeiger / Verweis zeigt tatsächlich auf ein lebendiges Objekt seines Basistyps. Hier ist ein Beispiel: {...}
Einfache Antwort: Im Allgemeinen können Sie diese Fehler nicht abfangen, und der Grund dafür ist, dass es ähnliche Konstrukte gibt, die vollkommen in Ordnung sind, so dass der Compiler die Semantik aller Funktionen kennen müsste, um Sie warnen zu können.
In einfacheren Fällen, wie zum Beispiel die Adresse eines temporären zu erhalten, warnen viele Compiler Sie bereits, aber im allgemeinen Fall ist es ziemlich schwierig, wenn nicht unmöglich für den Compiler zu wissen.
Für ein ähnliches Beispiel zu .c_str() in Erwägung ziehen:
Der Aufruf von begin gibt ein temporäres, ähnlich wie der Ausdruck (a+b) zurück, und Sie rufen eine Memberfunktion dieses temporären ( operator* ) auf, die ein const char* zurückgibt, das Ihrem Original sehr ähnlich ist Fall (aus der Sicht der beteiligten Typen). Das Problem ist, dass in diesem Fall der Hinweis nach dem Aufruf noch gültig ist, während er in Ihrem ( .c_str() ) nicht gültig ist, sondern Teil der Semantik der Operation ist, nicht die Syntax, die der Compiler für Sie überprüfen kann . Dasselbe gilt für das Beispiel .get() , der Compiler weiß nicht, ob der zurückgegebene Verweis auf ein Objekt ist, das nach dem Ausdruck gültig ist oder nicht.
All diese fallen unter die Kategorie "Undefiniertes Verhalten".
Tags und Links c++