Wie habe ich aus einer 8-Bit-Ganzzahl einen Wert erhalten, der größer als 8 Bit ist?

Ich habe einen extrem bösen Käfer aufgespürt, der sich hinter diesem kleinen Juwel versteckt. Mir ist bekannt, dass gemäß der C ++ - Spezifikation signierte Überläufe ein undefiniertes Verhalten sind, jedoch nur dann, wenn der Überlauf auftritt, wenn der Wert auf Bitbreite erweitert wird sizeof(int). So wie ich es verstehe, sollte das Inkrementieren von a charniemals undefiniertes Verhalten sein, solange sizeof(char) < sizeof(int). Das erklärt aber nicht, wie cman einen unmöglichen Wert bekommt . Wie kann eine 8-Bit-Ganzzahl cWerte enthalten, die größer als ihre Bitbreite sind?

Code

// Compiled with gcc-4.7.2
#include <cstdio>
#include <stdint.h>
#include <climits>

int main()
{
   int8_t c = 0;
   printf("SCHAR_MIN: %i\n", SCHAR_MIN);
   printf("SCHAR_MAX: %i\n", SCHAR_MAX);

   for (int32_t i = 0; i <= 300; i++)
      printf("c: %i\n", c--);

   printf("c: %i\n", c);

   return 0;
}

Ausgabe

SCHAR_MIN: -128
SCHAR_MAX: 127
c: 0
c: -1
c: -2
c: -3
...
c: -127
c: -128  // <= The next value should still be an 8-bit value.
c: -129  // <= What? That's more than 8 bits!
c: -130  // <= Uh...
c: -131
...
c: -297
c: -298  // <= Getting ridiculous now.
c: -299
c: -300
c: -45   // <= ..........

Probieren Sie es auf ideone aus.

Dies ist ein Compiler-Fehler.

Obwohl es eine gültige Konsequenz ist, unmögliche Ergebnisse für undefiniertes Verhalten zu erhalten, enthält Ihr Code tatsächlich kein undefiniertes Verhalten. Was ist passiert , dass der Compiler denkt ist das Verhalten nicht definiert und optimiert entsprechend.

Wenn cist wie folgt definiert int8_t, und int8_tfördert auf int, dann c--sollte die Subtraktion auszuführen c - 1in intArithmetik und das Ergebnis zurück zu konvertieren int8_t. Die Subtraktion in intläuft nicht über, und die Konvertierung von Integralwerten außerhalb des Bereichs in einen anderen Integraltyp ist gültig. Wenn der Zieltyp signiert ist, ist das Ergebnis implementierungsdefiniert, es muss jedoch ein gültiger Wert für den Zieltyp sein. (Und wenn der Zieltyp nicht signiert ist, ist das Ergebnis genau definiert, aber das gilt hier nicht.)

Ein Compiler kann Fehler aufweisen, die nicht dem Standard entsprechen, da andere Anforderungen bestehen. Ein Compiler sollte mit anderen Versionen von sich selbst kompatibel sein. Es kann auch erwartet werden, dass es in gewisser Weise mit anderen Compilern kompatibel ist und auch einigen Überzeugungen über das Verhalten entspricht, die von der Mehrheit seiner Benutzer gehalten werden.

In diesem Fall scheint es sich um einen Konformitätsfehler zu handeln. Der Ausdruck c--sollte cauf ähnliche Weise wie manipuliert werden c = c - 1. Hier wird der Wert von crechts zum Typ heraufgestuft int, und dann findet die Subtraktion statt. Da diese Subtraktion cim Bereich von liegt int8_t, läuft sie nicht über, kann jedoch einen Wert erzeugen, der außerhalb des Bereichs von liegt int8_t. Wenn dieser Wert zugewiesen wird, erfolgt eine Konvertierung zurück in den Typ, int8_tsodass das Ergebnis wieder in den Typ passt c. Im Fall außerhalb des Bereichs hat die Konvertierung einen implementierungsdefinierten Wert. Ein Wert außerhalb des Bereichs von int8_tist jedoch kein gültiger implementierungsdefinierter Wert. Eine Implementierung kann nicht "definieren", dass ein 8-Bit-Typ plötzlich 9 oder mehr Bits enthält. Wenn der Wert implementierungsdefiniert ist, bedeutet dies, dass etwas im Bereich von int8_tproduziert wird und das Programm fortgesetzt wird. Der C-Standard ermöglicht dabei Verhaltensweisen wie Sättigungsarithmetik (bei DSPs üblich) oder Wrap-Around (Mainstream-Architekturen).

Der Compiler verwendet einen breiteren zugrunde liegenden Maschinentyp, wenn Werte kleiner ganzzahliger Typen wie int8_toder bearbeitet werden char. Wenn eine Arithmetik durchgeführt wird, können Ergebnisse, die außerhalb des Bereichs des Typs mit kleinen ganzen Zahlen liegen, in diesem breiteren Typ zuverlässig erfasst werden. Um das von außen sichtbare Verhalten beizubehalten, dass die Variable ein 8-Bit-Typ ist, muss das breitere Ergebnis in den 8-Bit-Bereich gekürzt werden. Dazu ist expliziter Code erforderlich, da die Maschinenspeicherorte (Register) breiter als 8 Bit sind und mit den größeren Werten zufrieden sind. Hier hat der Compiler es versäumt, den Wert zu normalisieren , und ihn einfach so übergeben, printfwie er ist. Der Konvertierungsspezifizierer %iin printfhat keine Ahnung, dass das Argument ursprünglich aus int8_tBerechnungen stammt. es funktioniert nur mit einemint Streit.

Ich kann dies nicht in einen Kommentar einfügen, daher poste ich ihn als Antwort.

Aus irgendeinem sehr seltsamen Grund ist der --Bediener der Schuldige.

Getestet habe ich den Code auf Ideone geschrieben und ersetzt c--mit c = c - 1und die Werte blieben im Bereich [-128 ... 127]:

c: -123
c: -124
c: -125
c: -126
c: -127
c: -128 // about to overflow
c: 127  // woop
c: 126
c: 125
c: 124
c: 123
c: 122

Freaky ey? Ich weiß nicht viel darüber, was der Compiler mit Ausdrücken wie i++oder macht i--. Es ist wahrscheinlich, dass der Rückgabewert auf a erhöht intund weitergegeben wird. Das ist die einzige logische Schlussfolgerung, die ich ziehen kann, weil Sie tatsächlich Werte erhalten, die nicht in 8-Bit passen.

Ich vermute, dass die zugrunde liegende Hardware immer noch ein 32-Bit-Register verwendet, um dieses int8_t zu halten. Da die Spezifikation kein Überlaufverhalten vorschreibt, prüft die Implementierung nicht auf Überlauf und ermöglicht auch das Speichern größerer Werte.

Wenn Sie die lokale Variable markieren, während volatileSie die Verwendung von Speicher erzwingen, und folglich die erwarteten Werte innerhalb des Bereichs erhalten.

Der Assembler-Code zeigt das Problem:

:loop
mov esi, ebx
xor eax, eax
mov edi, OFFSET FLAT:.LC2   ;"c: %i\n"
sub ebx, 1
call    printf
cmp ebx, -301
jne loop

mov esi, -45
mov edi, OFFSET FLAT:.LC2   ;"c: %i\n"
xor eax, eax
call    printf

EBX sollte mit FF nach dem Dekrement anded werden, oder nur BL sollte mit dem Rest von EBX clear verwendet werden. Neugierig, dass es sub anstelle von dec verwendet. Die -45 ist geradezu mysteriös. Es ist die bitweise Inversion von 300 & 255 = 44. -45 = ~ 44. Irgendwo besteht eine Verbindung.

Es macht viel mehr Arbeit mit c = c - 1:

mov eax, ebx
mov edi, OFFSET FLAT:.LC2   ;"c: %i\n"
add ebx, 1
not eax
movsx   ebp, al                 ;uses only the lower 8 bits
xor eax, eax
mov esi, ebp

Es wird dann nur der niedrige Teil von RAX verwendet, sodass es auf -128 bis 127 beschränkt ist. Compiler-Optionen "-g -O2".

Ohne Optimierung wird der richtige Code erzeugt:

movzx   eax, BYTE PTR [rbp-1]
sub eax, 1
mov BYTE PTR [rbp-1], al
movsx   edx, BYTE PTR [rbp-1]
mov eax, OFFSET FLAT:.LC2   ;"c: %i\n"
mov esi, edx

Es ist also ein Fehler im Optimierer.

Verwenden Sie %hhdanstelle von %i! Sollte Ihr Problem lösen.

Was Sie dort sehen, ist das Ergebnis von Compiler-Optimierungen in Kombination mit der Anweisung an printf, eine 32-Bit-Nummer zu drucken und dann eine (angeblich 8-Bit-) Nummer auf den Stapel zu schieben, der wirklich zeigergroß ist, da der Push-Opcode in x86 so funktioniert.

Ich denke, dies geschieht durch Optimierung des Codes:

for (int32_t i = 0; i <= 300; i++)
      printf("c: %i\n", c--);

Der Compilator verwendet die int32_t iVariable sowohl für ials auch c. Deaktivieren Sie die Optimierung oder führen Sie eine direkte Besetzung durch printf("c: %i\n", (int8_t)c--);

cist selbst definiert als int8_t, aber wenn es in Betrieb ++oder --darüber ist int8_t, wird es implizit zuerst in intund das Ergebnis der Operation konvertiert, stattdessen wird der interne Wert von c mit printf gedruckt, was zufällig ist int.

Siehe den tatsächlichen Wert des cnach gesamter Schleife, vor allem nach dem letzten Abnahme

-301 + 256 = -45 (since it revolved entire 8 bit range once)

Es ist der richtige Wert, der dem Verhalten ähnelt -128 + 1 = 127

cbeginnt mit der Verwendung des intGrößenspeichers, wird jedoch so int8_tgedruckt, als würde er nur mit sich selbst gedruckt 8 bits. Verwendet alles, 32 bitswenn es als verwendet wirdint

[Compiler Bug]

Ich denke, es ist passiert, weil Ihre Schleife so lange dauert, bis int i 300 und c -300 wird. Und der letzte Wert ist weil

printf("c: %i\n", c);