Un bug dans le décalage ?

Bonjour :coucou:

Voici un petit programme dont le résultat me paraît bizarre (Code::Blocks 13.12, Windows 7)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <iostream> #include <fstream>   using namespace std;   int main() { unsigned n = 32 ;   printf("%x, %x", 0xFFFFFFFF>>n, 0xFFFFFFFF>>32);   return 0; }

---

Résultat : ffffffff, 0

Si on essaye d'autres valeurs, tout se passe comme si n était calculé modulo 32 avant de faire le décalage.
32 = width of type : il y a d'ailleurs un warning à ce sujet.
Bien sur (!), le problème disparaît si on remplace la ligne 9 par const unsigned n = 32 ;
Une idée de ce qui se passe vraiment ?

Merci d'avance

En fait, la blague, c'est que 32 est une constante de type /*signed*/ int, alors que ton n est un unsigned intet 0xffffffff est (int32)-1

La différence est dans la propagation du bit de signe.

avec le code suivant, tu auras normalement le meme résultat.

Code:

---

1 2 3 4 5 6 7 8

#include <cstdio> using namespace std;   int main() { unsigned n = 32 ; printf("%x, %x", 0xF0000000>>n, 0xF0000000>>32); return 0; }

---

Les entiers sont codé sur 32 bit, donc lorsque tu effectue un décalage, il est impossible de décalé de 32bit ou plus, c'est pourquoi un modulo est appliqué.

en gros l'opérateur va appliquer un modulo selon cette formule:

Code:

---

vardroite %= sizeof(vargauche)*4;

---

et ce afin d'évité un décalage de bit qui serait impossible.

En utilisant un long long (codé sur 64bit) on repousse donc cette limite à 64 d'où le code suivant:

Code:

---

1 2 3 4 5 6 7 8

#include <cstdio> using namespace std;   int main() { unsigned n = 32 ; printf("%x, %x", (long long int)(0xFFFFFFFF)>>n, 0xF0000000>>32); return 0; }

---

EDIT: mon explication ne fonctionne que si la variable de droite est une variable et non une constante, pour les constante, l'explication est donnée par mon vdd :).

Bonjour
Merci à tous pour vos réponses.

@ eternel (j'ai légèrement modifié mon post pendant ta réponse, mais cela ne change pas grand chose).

Citation:

---

32 est une constante de type*/*signed*/*int, alors que ton n est un*unsigned*int

---

Si on remplace la ligne 9 par int n = 32 ;, le problème subsiste.

Citation:

---

#include <cstdio>

---

Cette modification ne change rien.

@ skeud

Citation:

---

Les entiers sont codé sur 32 bit, donc lorsque tu effectue un décalage, il est impossible de décalé de 32bit ou plus

---

Pourtant cela marche très bien avec la valeur numérique (ou une constante) : on peut même remplacer 32 par une valeur plus grande.

Citation:

---

pour les constante, l'explication est donnée par mon vdd

---

vdd : késako ?

@ gl

Citation:

---

The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.

---

Là, je crois que tout est dit ! Juste un bémol : avec un tel comportement, un simple warning est-il suffisant ?

Cordialement

C'est un comportement indéfini :

Citation:

---

The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.

---

A partir de ce moment, il ne sert à rien de chercher une explication logique du comportement sur les règles de promotion, la gestion de dépassement, etc. à partir du langage. L'implémentation est en droit de faire ce qu'elle veut (y compris avec un comportement aléatoire), la documentation du compilateur peut éventuellement décrire le comportement de ce compilateur dans ce cas, mais ce n'est pas extrapolable.

Pourquoi, il y a une différence dans les deux cas ? Car dans un cas tu as une constante défini à la compilation pas dans l'autre et donc pas le même code généré, et le comportement indéfini "à la compilation" n'est pas le même qu'un runtime avec le compilateur utilisé ici.
Sur la version de gcc que j'ai sous la main, en déclarant n const, on retrouve le même comportement qu'en utilisant la constante littéral.

Citation:

---

Envoyé par serge17

vdd : késako ?

---

voisin du dessus ^^.

(suite)

@ skeud

Citation:

---

vdd = voisin du dessus.

---

Je prends bonne note ! ;)

@ gl Le décalage se comporte comme tu le dis et on n'y peut pas grand chose. Mais je ne comprends pas la logique de l'implémentation.
Le résultat attendu est clairement 0 : si on fait une boucle avec l'instruction LSR (assembleur), le résultat va être nul à partir d'un certain rang. C'est d'ailleurs ce qui se passe avec les valeurs littérales ou les constantes. Quel est l'intérêt de faire différemment avec les variables ?

D'autre part, utiliser une variable négative ne peut provenir que d'une erreur de programmation indétectable à la compilation. On devrait avoir une procédure du genre de celle utilisée pour les divisions par 0 et non « an undefined behavior » : difficile de débuguer un programme qui fait n'importe quoi on ne sait où !

J'ai découvert ce comportement par hasard. Mon programme (pas le ECM de mon post !) fonctionnait correctement pour toutes les valeurs testées jusqu'à ce que j'essaye 32 : un coup de bol !

En tout cas, merci à tous :lahola:

Je passe en résolu (mais vous pouvez toujours ajouter un petit mot !)

Cordialement

Citation:

---

Envoyé par serge17

Quel est l'intérêt de faire différemment avec les variables ?

---

Potentiellement par simplicité. Le compile-time peut faire des hypothèses que le runtime ne peut pas.

Citation:

---

Envoyé par serge17

D'autre part, utiliser une variable négative ne peut provenir que d'une erreur de programmation indétectable à la compilation. On devrait avoir une procédure du genre de celle utilisée pour les divisions par 0 et non « an undefined behavior » : difficile de débuguer un programme qui fait n'importe quoi on ne sait où !

---

Ici le souci n'est pas l'utilisation d'une variable négative (qui est aussi un UB sur le second opérande mais implementation-defined sur le premier) mais d'un décalage plus grand que la taille.

Pourquoi ne pas imposer une erreur ? Pour permettre au compilateur d'avoir une implémentation efficace sur certaine plateforme, lui permettre de proposer une implémentation particulière (documenté dans sa doc et potentiellement configurable) pertinente dans son domaine d'utilisation, laisser la porte ouverte à certaines optimisations, des comportements pré-existants sur lesquels on n'a pas voulu revenir, etc.
En pratique, les UB sont un choix volontaire et réfléchis.

Si tu veux détecter ces erreurs en phase de debug, il existe assert() dont c'est clairement le rôle.

Merci gl pour toutes ces précisions :ccool: