Décalage à droite signé = résultat étrange?

Question

J'aidais quelqu'un à faire ses devoirs et j'ai été confronté à ce problème étrange. Le problème est d'écrire une fonction qui inverse l'ordre des octets d'un entier signé (C'est ainsi que la fonction a été spécifiée de toute façon), et c'est la solution que je suis venu avec:

int reverse(int x) 
{ 
    int reversed = 0; 

    reversed = (x & (0xFF << 24)) >> 24; 
    reversed |= (x & (0xFF << 16)) >> 8; 
    reversed |= (x & (0xFF << 8)) << 8; 
    reversed |= (x & 0xFF) << 24; 

    return reversed; 
} 

Si vous passez 0xFF000000 à cette fonction, la première affectation aura pour résultat 0xFFFFFFFF. Je ne comprends pas vraiment ce qui se passe, mais je sais que cela a quelque chose à voir avec les conversions entre les signataires et les non signés, ou quelque chose comme ça.

Si j'applique ul à 0xFF cela fonctionne très bien, ce que je suppose est parce qu'il est forcé à non signé puis converti en signé ou quelque chose dans cette direction. Le code résultant change également; sans le spécificateur ul, il utilise sar (arithmétique de décalage à droite), mais comme non signé, il utilise shr comme prévu.

J'apprécierais vraiment si quelqu'un pourrait éclaircir cela pour moi. Je suis supposé savoir ce genre de choses, et je pensais que c'était le cas, mais je ne suis pas vraiment sûr de ce qui se passe ici.

Merci d'avance!

Answer 1

Depuis x est un signé quantité, le résultat de (x & (0xFF << 24)) est 0xFF000000 qui est également signé et donc un nombre négatif depuis le haut (signe) bit est défini. L'opérateur >> sur int (une valeur signée) exécute extension de signe (Edit: bien que ce comportement soit indéfini et spécifique à l'implémentation) et propage la valeur de bit de signe 1 lorsque la valeur est décalée vers la droite.

Vous devez réécrire la fonction comme suit pour travailler exclusivement sur des valeurs non signées:

unsigned reverse(unsigned x) 
{ 
    unsigned int reversed = 0; 

    reversed = (x & (0xFF << 24)) >> 24; 
    reversed |= (x & (0xFF << 16)) >> 8; 
    reversed |= (x & (0xFF << 8)) << 8; 
    reversed |= (x & 0xFF) << 24; 

    return reversed; 
} 

Answer 2

x est signé, de sorte que le bit est utilisé pour le signe. 0xFF000000 signifie "négatif 0x7F000000". Lorsque vous effectuez le décalage, le résultat est "Signe étendu": le chiffre binaire ajouté à gauche pour remplacer l'ancien MSB déplacé vers la droite est toujours le même que le signe de la valeur. Alors

0xFF000000 >> 1 == 0xFF800000 
0xFF000000 >> 2 == 0xFFC00000 
0xFF000000 >> 3 == 0xFFE00000 
0xFF000000 >> 4 == 0xFFF00000 

Si la valeur étant décalée est non signé, ou si le décalage est vers la gauche, le nouveau bit serait 0. Il est seulement en droit-quarts des valeurs signées qui extension de signe entrent en jeu.

Answer 3

À partir de vos résultats, nous pouvons déduire que vous êtes sur une machine 32 bits.

(x & (0xFF << 24)) >> 24 

Dans cette expression 0xFF est un int, donc 0xFF << 24 est aussi un int, comme x.

Lorsque vous effectuez une opération de bit & entre deux int, le résultat est aussi un int et dans ce cas, la valeur est 0xFF000000 qui, sur une machine 32 bits signifie que le bit de signe est défini, vous avez donc un nombre négatif.

Le résultat de l'exécution d'un décalage vers la droite sur un objet de type signé avec une valeur négative est défini par l'implémentation.Dans votre cas, le décalage arithmétique est conservé.

Si vous effectuez un décalage vers la droite d'un type non signé, vous obtiendrez les résultats attendus pour une fonction d'inversion d'octet. Vous pouvez réaliser cela en faisant opérande l'un ou l'autre des opérandes bit à bit & un type non signé forçant la conversion des deux opérandes au type non signé. (Cela est vrai sur toute mise en œuvre où un signé int ne peut pas tenir toute la gamme possible de valeurs positives d'un unsigned int qui est presque toutes les implémentations.) Changement

Answer 4

droit sur les types signés est mise en œuvre définie, en particulier le compilateur est libre de faire un changement arithmétique ou logique à sa guise. C'est quelque chose que vous ne remarquerez pas si la valeur concrète que vous traitez est positive, mais dès qu'elle est négative, vous risquez de tomber dans un piège.

Juste ne le faites pas, ce n'est pas portable.

Answer 5

Si ce code est en Java, vous devez utiliser « >>> » qui est un décalage droit non signé, sinon il signera d'étendre la valeur

Answer 6

Si vous voulez que cela fonctionne même sur les plates-formes al à la fois signé et entiers non signés, changer

(x & (0xFF << 24)) >> 24 

dans

(x >> 24) & 0xFF