Comment obtenir une valeur supérieure à 8 bits à partir d'un entier de 8 bits?

J'ai retrouvé un insecte extrêmement méchant qui se cachait derrière ce petit bijou. Je suis conscient que selon la spécification C ++, les débordements signés sont un comportement indéfini, mais uniquement lorsque le débordement se produit lorsque la valeur est étendue à la largeur en bits sizeof(int). Si je comprends bien, incrémenter un charne devrait jamais être un comportement indéfini aussi longtemps que sizeof(char) < sizeof(int). Mais cela n'explique pas comment cobtenir une valeur impossible . En tant qu'entier 8 bits, comment peut ccontenir des valeurs supérieures à sa largeur en bits?

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;
}

Production

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   // <= ..........

Découvrez-le sur ideone.

Ceci est un bogue du compilateur.

Bien qu'obtenir des résultats impossibles pour un comportement non défini soit une conséquence valide, il n'y a en fait aucun comportement non défini dans votre code. Ce qui se passe, c'est que le compilateur pense que le comportement n'est pas défini et optimise en conséquence.

Si cest défini comme int8_t, et int8_tpromeut vers int, alors c--est censé effectuer la soustraction c - 1en intarithmétique et reconvertir le résultat en int8_t. La soustraction dans intne déborde pas et la conversion des valeurs intégrales hors plage en un autre type intégral est valide. Si le type de destination est signé, le résultat est défini par l'implémentation, mais il doit être une valeur valide pour le type de destination. (Et si le type de destination n'est pas signé, le résultat est bien défini, mais cela ne s'applique pas ici.)

Un compilateur peut avoir des bogues autres que des non-conformités à la norme, car il existe d'autres exigences. Un compilateur doit être compatible avec d'autres versions de lui-même. On peut également s'attendre à ce qu'il soit compatible à certains égards avec d'autres compilateurs, et aussi à se conformer à certaines croyances sur le comportement qui sont détenues par la majorité de sa base d'utilisateurs.

Dans ce cas, cela semble être un bogue de conformité. L'expression c--doit manipuler cd'une manière similaire à c = c - 1. Ici, la valeur de cà droite est promue en type int, puis la soustraction a lieu. Comme se csitue dans la plage de int8_t, cette soustraction ne débordera pas, mais elle peut produire une valeur hors de la plage de int8_t. Lorsque cette valeur est affectée, une conversion a lieu de nouveau au type int8_tafin que le résultat rentre dans c. Dans le cas hors limites, la conversion a une valeur définie par l'implémentation. Mais une valeur hors de la plage de int8_tn'est pas une valeur définie par l'implémentation valide. Une implémentation ne peut pas "définir" qu'un type 8 bits contient soudainement 9 bits ou plus. Pour que la valeur soit définie par la mise en œuvre, cela signifie que quelque chose de l'ordre de int8_test produit et le programme se poursuit. La norme C permet ainsi des comportements tels que l'arithmétique de saturation (commune sur les DSP) ou le bouclage (architectures grand public).

Le compilateur utilise un type de machine sous-jacent plus large lors de la manipulation de valeurs de petits types entiers tels que int8_tou char. Lorsque l'arithmétique est effectuée, les résultats qui sont hors de portée du type petit entier peuvent être capturés de manière fiable dans ce type plus large. Pour conserver le comportement visible de l'extérieur selon lequel la variable est de type 8 bits, le résultat plus large doit être tronqué dans la plage de 8 bits. Un code explicite est nécessaire pour ce faire, car les emplacements de stockage de la machine (registres) sont plus larges que 8 bits et satisfaits des valeurs plus élevées. Ici, le compilateur a négligé de normaliser la valeur et l'a simplement passée printftelle quelle . Le spécificateur de conversion %idans printfn'a aucune idée que l'argument provenait à l'origine de int8_tcalculs; il s'agit simplement de travailler avec unint argument.

Je ne peux pas intégrer cela dans un commentaire, donc je le poste comme réponse.

Pour une raison très étrange, l' --opérateur se trouve être le coupable.

J'ai testé le code affiché sur Ideone et remplacé c--par c = c - 1et les valeurs sont restées dans la plage [-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? Je ne sais pas grand-chose de ce que le compilateur fait aux expressions comme i++ou i--. Cela promeut probablement la valeur de retour à an intet la transmet. C'est la seule conclusion logique que je puisse trouver car vous obtenez en fait des valeurs qui ne peuvent pas tenir dans 8 bits.

Je suppose que le matériel sous-jacent utilise toujours un registre 32 bits pour contenir ce int8_t. Étant donné que la spécification n'impose pas de comportement pour le débordement, l'implémentation ne vérifie pas le débordement et permet également de stocker des valeurs plus importantes.

Si vous marquez la variable locale comme volatilevous obligez à utiliser la mémoire pour elle et par conséquent obtenir les valeurs attendues dans la plage.

Le code assembleur révèle le problème:

: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 doit être anded avec FF post décrément, ou seul BL doit être utilisé avec le reste d'EBX clear. Curieux qu'il utilise sous au lieu de déc. Le -45 est complètement mystérieux. C'est l'inversion bit à bit de 300 & 255 = 44. -45 = ~ 44. Il y a une connexion quelque part.

Il nécessite beaucoup plus de travail en utilisant 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

Il n'utilise alors que la partie basse de RAX, donc il est limité à -128 à 127. Options du compilateur "-g -O2".

Sans optimisation, il produit un code correct:

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

C'est donc un bug dans l'optimiseur.

Utilisez %hhdplutôt que %i! Devrait résoudre votre problème.

Ce que vous voyez là est le résultat des optimisations du compilateur combinées avec vous disant à printf d'imprimer un nombre 32 bits, puis de pousser un nombre (supposé 8 bits) sur la pile, qui est vraiment de la taille d'un pointeur, car c'est ainsi que fonctionne l'opcode push dans x86.

Je pense que cela se fait par optimisation du code:

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

Le compilateur utilise la int32_t ivariable à la fois pour iet c. Désactivez l'optimisation ou effectuez une diffusion directe printf("c: %i\n", (int8_t)c--);

cest lui-même défini comme int8_t, mais lors de l'opération ++ou au- --dessus, int8_til est implicitement converti en premier intet le résultat de l'opération à la place, la valeur interne de c est imprimée avec printf qui se trouve être int.

Voir la valeur réelle de caprès boucle entière, surtout après la dernière décrément

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

c'est la valeur correcte qui ressemble au comportement -128 + 1 = 127

ccommence à utiliser la intmémoire de taille mais imprimé comme int8_tlors de l'impression en tant que lui-même en utilisant uniquement 8 bits. Utilise tout 32 bitslorsqu'il est utilisé commeint

[Bogue du compilateur]

Je pense que c'est arrivé parce que votre boucle ira jusqu'à ce que l'int i devienne 300 et c devienne -300. Et la dernière valeur est que

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