Décalage à droite et entier signé

Sur mon compilateur, le pseudo-code suivant (les valeurs remplacé par binaire):

sint32 word = (10000000 00000000 00000000 00000000);
word >>= 16;

produit un word avec un champ de bits qui ressemble à ceci:

(11111111 11111111 10000000 00000000)

Ma question est, puis-je compter sur ce comportement pour toutes les plates-formes et les compilateurs C++?

OriginalL'auteur Anne Quinn | 2011-09-22

  1. 23

    À partir du lien suivant:

    INT34-C. Ne pas déplacer une expression par un nombre négatif de bits ou supérieur ou égal au nombre de bits qui existent dans l'opérande

    Non Conforme À L'Exemple De Code (Décalage À Droite)

    Le résultat de E1 >> E2 est E1 décalés vers la droite E2 positions de bits. Si E1 a un type non signé ou si E1 a signé un type et un non négatif, la valeur du résultat est la partie entière du quotient de E1 /2E2. Si E1 a signé un type et une valeur négative, la valeur est définie par l'implémentation et peut être une arithmétique (signé) maj:

    Décalage à droite et entier signé

    ou logique (non signé) maj:

    Décalage à droite et entier signé

    Cette non conforme à l'exemple de code ne parvient pas à tester si l'opérande de droite est supérieure ou égale à la largeur de la promotion opérande de gauche, permettant à un comportement indéfini.

    unsigned int ui1;
unsigned int ui2;
unsigned int uresult;

/* Initialize ui1 and ui2 */

uresult = ui1 >> ui2;

    De faire des hypothèses quant à savoir si une maj de droite est mis en œuvre comme une opération arithmétique (signé) maj ou logique (non signé) poste peut également conduire à des vulnérabilités. Voir la recommandation INT13-C. à l'aide d'opérateurs au niveau du bit uniquement sur unsigned opérandes.

    Il n'y avait pas de recommandation qui en fait est penché sur cette question? Parce que basé sur le nom de la règle, il ne s'applique pas ici... vous êtes juste de citer certaines des informations de fond.
    La 2ème, lien plus pertinent a été déplacé. Le nouveau lien est wiki.sei.cmu.edu/confluence/display/c/...

    OriginalL'auteur Andrew Clark

  2. 13

    Non, vous ne pouvez pas compter sur ce comportement. Droit déplaçant des quantités négatives (qui je suppose que votre exemple est à traiter) est définie par l'implémentation.

    Ok, c'est juste. Je me demande encore, si le compilateur crée un fichier binaire qui utilise cette méthode, ne serait-il fonctionner comme prévu dans la plupart des matériels au moins?
    Si vous compilez quelque chose pour un certain architecture, qui est censé être le même dans toutes les implémentations de l'architecture. x86, par exemple, a différentes opérations de décalage pour la connexion de l'extension et de la non-inscription de l'extension des quarts de travail, et c'est le compilateur qui décide de l'utiliser. Il ne sera probablement pas travailler du tout (lire: tout, et pas seulement ce comportement) sur d'autres architectures.
    C'est horrible ...

    OriginalL'auteur R. Martinho Fernandes

  3. 6

    En C++, pas de. Elle est mise en œuvre et/ou dépendants de la plateforme.

    Dans quelques autres langues, oui. En Java, par exemple, l' >> opérateur est défini de manière précise à toujours remplir à l'aide de la gauche de la plupart des bits (ce qui permet de préserver signe). L' >>> opérateur remplit à l'aide de 0s. Donc, si vous voulez la fiabilité de comportement, une option possible serait de passer à une autre langue. (Bien évidemment, cela peut ne pas être une option en fonction de vos circonstances.)

    OriginalL'auteur Keith Irwin

  4. 3

    Autant que je sache les nombres entiers peuvent être représentées par le signe-amplitude en c++, auquel cas l'extension du signe permettrait de combler avec de 0. Si vous ne pouvez pas compter sur cela.

    Vous avez raison. La norme établit certaines exigences qui en font un complément à deux l'une représentation optimale, mais en général, les entiers signés peuvent être représentés en quelque sorte la mise en œuvre veut.

    OriginalL'auteur CodesInChaos