Wie aktiviere ich die Compiler-Warnung beim Vergleich von char und unsigned char?

Nehmen Sie zum Beispiel den folgenden C-Code:

int main(int argc, char *argv[])
{
    signed char i;
    unsigned char count = 0xFF;

    for (i=0; i<count;i++)
    {
        printf("%x\n", i);
    }
    return 0;
}

Dieser Code läuft in einer Endlosschleife, auch wenn ich ihn wie folgt kompiliere:

# gcc -Wall -Wpedantic -Wconversion -Wsign-compare -Wtype-limits -Wsign-conversion test.c -o test

Kennt jemand ein Compiler-Flag, das vor solchen Problemen warnen sollte?

Nur um das klarzustellen, ich frage nicht, warum eine Endlosschleife kommt, sondern um zu wissen, ob es eine Möglichkeit gibt, dies mit einem Compiler oder einer statischen Analyse zu verhindern.

Das Flag -Wconversion fängt den Fehler nicht ab, da beide Operanden im Vergleich: i<countwerden Sie mithilfe von Integer-Promotions zu int befördert.

Es gibt kein Flag in gcc, das dies abfangen würde.

Abgesehen davon ist das Verhalten Ihres Codes undefiniert, da die Variable i überläuft, wenn sie den Wert hat 0x7F und wird erhöht: i++.

Wenn Sie bis zu einem bestimmten Wert iterieren möchten, stellen Sie sicher, dass der verwendete Typ diesen Wert darstellen kann.

i ist ein signed chares darüber hinaus inkrementieren SCHAR_MAX hat eine implementierungsdefinierte Wirkung. Die Berechnung i + 1 wird nach der Förderung von durchgeführt i zu int und es läuft nicht über (es sei denn sizeof(int) == 1 und SCHAR_MAX == INT_MAX). Dieser Wert liegt jedoch außerhalb des Bereichs von i und da i hat einen signierten Typ, Entweder ist das Ergebnis implementierungsdefiniert oder es wird ein implementierungsdefiniertes Signal ausgelöst. (C11 6.3.1.3p3 Ganzzahlen mit und ohne Vorzeichen).

Per Definition ist der Compiler die Implementierung, daher wird das Verhalten für jedes spezifische System und auf x86-Architekturen definiert, wo das Speichern des Werts dazu führt, dass die niederwertigen Bits maskiert werden. gcc Beachten Sie, dass der Schleifentest definitiv konstant ist, was ihn zu einer Endlosschleife macht.

Beachten Sie, dass clang erkennt der Dauertest auch nicht, aber clang 3.9.0 wird wenn count wird als deklariert constund es wird eine Warnung ausgegeben, wenn i < count wird durch ersetzt i < 0xffnicht wie gcc.

Keiner der Compiler beschwert sich über das Problem des vorzeichenbehafteten / vorzeichenlosen Vergleichs, da beide Operanden tatsächlich heraufgestuft werden int vor dem Vergleich.

Sie haben hier ein bedeutendes Problem gefunden, das besonders wichtig ist, da einige Codierungskonventionen darauf bestehen, den kleinstmöglichen Typ für alle Variablen zu verwenden, was zu solchen Kuriositäten führt wie int8_t oder uint8_t Loop-Index-Variablen. Solche Entscheidungen sind in der Tat fehleranfällig, und ich habe noch keinen Weg gefunden, den Compiler dazu zu bringen, den Programmierer vor dummen Fehlern wie dem von Ihnen geposteten zu warnen.

Seit i ist ein signed charsein Wert reicht von -128 to 127 typisch. Wohingegen count ein sein unsigned char wird der Wert zugewiesen 255 (0xFF).

Innerhalb der Schleife, wann i Wert kommt 127 und wieder erhöht wird, erreicht es nie 128 und kommt zu -128 und kommt dann wieder dazu 127 und rollt dann wieder um -128, usw. Der Wert von i wird für immer geringer sein als der Wert von count innerhalb der Schleife und daher kann die Schleife niemals enden!

Dies geschieht aufgrund des Überlaufs des Datentyps und es muss darauf geachtet werden, die Ausdrücke kritisch zu prüfen, bei denen automatische Typumwandlungen stattfinden können, da sie keine Warnung ausgeben.

BEARBEITEN: Aus der GCC-Dokumentation,

-Wconversion: Warnt vor impliziten Konvertierungen, die einen Wert ändern können.

Hier erhalten wir eine Inkonsistenz aufgrund eines Vergleichs und nicht einer Zuordnung.

Es gibt keine Warnung, dies zu fangen weil in diesem Code vom Standpunkt des Compilers nichts fragwürdig ist.

1. Wie in anderen Antworten erwähnt, wird die Vergleichslinie effektiv behandelt als

   for (i=0; (int)i<(int)count; i++)
   

   • Wie beschrieben in Begründung für International Standard – Programmiersprachen – CAbschnitt 6.3.1.1, wählten sie für implizite Typkonvertierungen beim Vergleichen von Werten den „Werterhaltenden“ Ansatz, da dieser weniger Potenzial für unerwartete Vergleichsergebnisse hat.

     • Beachten Sie, dass Ihr Programm “falsch” läuft speziell weil das Ergebnis des arithmetischen Vergleichs ist das erwartete.

   • Wenn diese wären ints, diese “werterhaltende” Semantik wäre unmöglich zu erreichen – weil an int ist in der Regel ein Hardware-Typ (oder zumindest ist C darauf ausgelegt), und es gibt wenige (wenn überhaupt) Architekturen, die es zulassen, dass ein Operand signiert wird, während der andere unsigniert ist. Das ist der Hauptgrund dafür, dass ein Compiler eine Warnung „Vergleich zwischen signiert und unsigniert“ ausgibt wenn Sie ersetzen chars mit intist hier.

2. Für die Inkrementoperation gilt: i++,

   • Die gleiche oben verlinkte Begründung erwähnt an einigen Stellen, dass “stiller Überlauf” bei weitem die häufigste und erwartete Semantik ist. Es sogar soll in erster Linie “einen Mangel an Sensibilität in der C-Community für die Unterschiede zwischen vorzeichenbehafteter und vorzeichenloser Arithmetik” verursacht haben! Also auch hier nichts Verdächtiges.

Was letztendlich diese Verwirrung verursacht hat, ist Ihre Unachtsamkeit gegenüber dem int Förderung Semantik. Was das Verhalten des Codes verursacht hat unerwartet für dich (kein schlechtes Gewissen, das wusste ich auch nicht, bevor ich die anderen Antworten gelesen habe!). Doch es stellt sich heraus, es ist für den Standard durchaus zu erwarten – außerdem davon diktiert. “Unkenntnis des Gesetzes ist keine Entschuldigung”, wie sie sagen.