Überlauf bei vorzeichenbehafteter Arithmetik: den Compiler-Vertrag dokumentieren, bevor die Optimierung geändert wird

Worum es geht

GCC dokumentiert -fwrapv als Anforderung eines Wrap-Verhaltens für vorzeichenbehaftete Addition, Subtraktion und Multiplikation, während -ftrapv für diese Operationen Traps anfordert. Die Optionen wirken zusammen, und sowohl ihre Reihenfolge als auch ihr aktiver Zustand spielen eine Rolle. Es handelt sich um explizite Compiler-Verträge mit festgelegtem Geltungsbereich, nicht um austauschbare Mittel, um jede arithmetische Operation sicher zu machen. GCC-Optimierungsoptionen

Warum es wichtig ist

Ein Agent, der einen nur im Release-Build auftretenden Fehler untersucht, deaktiviert möglicherweise die Optimierung und hört dort auf. Das zeigt einen Unterschied in der Umgebung, lässt aber offen, welches arithmetische Verhalten eigentlich beabsichtigt ist. Bei Zählwerten, Längen und Offsets sollte vor der Wahl einer Implementierung entschieden werden, ob ein Ergebnis ausserhalb des gültigen Bereichs zurückgewiesen, begrenzt (gesättigt), verbreitert oder umgebrochen (Wrap) werden soll.

So wird es angewendet

• Die tatsächlich verwendeten Compiler-Flags für die betroffene Übersetzungseinheit erfassen, einschliesslich geerbter Build-Einstellungen. Compiler und Zielplattform festhalten, statt sich auf den Namen des Build-Profils zu verlassen.
• Die gültigen Wertebereiche der Operanden und die beabsichtigte Ergebnisstrategie direkt bei der Berechnung dokumentieren. Bei einer Allokationsgrösse auch die Zwischenberechnungen einbeziehen, statt nur den endgültigen Zieltyp zu betrachten.
• Vorgeschlagene Grenzfälle knapp innerhalb und ausserhalb des zulässigen Bereichs konstruieren. Die erwarteten Ergebnisse unabhängig davon festlegen, was die aktuell vorliegende ausführbare Datei zufällig ausgibt.
• Wenn eine Zurückweisung erforderlich ist, eine geprüfte arithmetische Operation oder eine mathematisch begründete Bereichsprüfung bevorzugen. Ist ein Wrap-Verhalten bewusst Teil des Vertrags, festhalten, welche Operationen und Übersetzungseinheiten sich darauf verlassen.
• Debug- und Release-Konfiguration mit denselben Testfällen vergleichen und anschliessend die relevanten Diagnosen prüfen. Das kleinste Beispiel aufbewahren, das zeigt, warum der gewählte Vertrag nötig ist.

Stolpersteine

Nicht davon ausgehen, dass ein breiterer Zieltyp eine Zwischenberechnung rettet, die in einem schmaleren Typ durchgeführt wurde. Ein Flag, das für Addition, Subtraktion und Multiplikation dokumentiert ist, ist kein pauschales Versprechen für Division, Shifts oder Zeiger. Vermeiden, Flags stillschweigend für das gesamte Projekt zu ändern, um eine einzelne lokale Operation zu reparieren. Die vorgeschlagenen Prüfungen sind ein Untersuchungsplan; hier wird kein Compiler-Experiment oder bestandener Grenzwerttest behauptet.