Erzwinge die Dereferenzierung des NULL-Pointers

8

Ich habe das sehr alte (und riesige) Win32-Projekt, das massive Überprüfungen mit dem NULL-Zeiger verwendet, indem es den Zeiger auf den dereferenzierten Zeiger verweist. So:

%Vor%

Und ja, Ich weiß, dass dieser Code dumm ist und refaktoriert werden muss . Aber es ist unmöglich wegen der großen Menge an Code. Im Moment muss ich dieses Projekt unter MacOS Sierra in Xcode kompilieren, was zu großen Problemen führt ... Es stellt sich heraus, dass die Bedingung im Release-Modus (mit Code-Optimierung) mit falschem Verhalten ausgeführt wird (sogenanntes undefiniertes Verhalten wegen Dereferenzierung von NULL) Zeiger).

Laut diesem Dokument für GCC gibt es eine Option -fno-delete -null-pointer-checks , scheint aber nicht für LLVM zu funktionieren, wenn die O1-, O2- oder O3-Optimierung aktiviert ist. Die Frage ist also: Wie kann ich den LLVM 8.0-Compiler zwingen, solche Dereferenzierungen zuzulassen?

UPDATE. Das wirklich funktionierende Beispiel, um das Problem zu überprüfen.

%Vor%

Bei -O0 und -O1 , something behält den Null-Test und der Code "funktioniert":

%Vor%

Aber ab -O2 und ist der Check optimiert :

%Vor%     
Alek Depler 02.12.2016, 08:41
quelle

1 Antwort

0

Führen Sie eine textbasierte Suche mit NULL durch. Führen Sie dann den Compiler im Warnmodus aus und drucken Sie alle Warnungen auf Papier aus (wenn Sie noch über eine solche Technologie verfügen). Ist nun für jede Null eine problematische Null oder eine gute Null? Wenn problematisch, benennen Sie es um XNULL.

Jetzt ist es wahrscheinlich, dass die C ++ - Überprüfungen auf einem kleinen System mit 640.000 installiert werden können, weil 640k für jeden ausreichen, aber nicht auf Ihrem modernen System mit vielen GB. Also streiche sie einfach einmal aus. Wenn das nicht der Fall ist. mache XNULL zu einem "Dummy-Objekt" mit einer gültigen Adresse in C ++ Augen.

(Aus dem Beispiel sieht es so aus, als wäre Code ein Lisp-Interpreter. Lisp benötigt sowohl einen Nullzeiger als auch einen Dummy-Zeiger, es gibt keine andere einfache Möglichkeit, den Interpreter zu schreiben).

    
Malcolm McLean 02.12.2016 10:39
quelle