Ce code d'opérateur de bits est-il des effets secondaires (terme utilisé dans le livre K&R C) ou des instructions de traitement dépendant de la machine?

~ 0 << 3 est toujours un bogue, aucun des deux exemples n'est correct.

• 0 est de type int qui est signé.
• ~ 0 convertira le contenu binaire en tous les uns: 0xFF ... FF .
• Lorsque vous laissez les données de décalage dans le bit de signe d'un entier signé, vous invoquez un comportement non défini. Même chose si vous déplacez à gauche un entier négatif.

Conclusion: aucun des deux exemples n'a une sortie déterministe et les deux peuvent planter ou afficher des déchets.

Dans le premier cas, il y a une coercition vers char seulement après la fin du calcul tandis que dans le second cas il y a une coercition vers char après le premier (~ 0 << 3) .

comme je l'ai dit dans les commentaires, il existe des conversions arithmétiques par défaut impliquées dans la coercition qui font la différence.

Premièrement, ~ 0 appelle comportement non défini car ~ 0 est une valeur entière signée avec tous les bits mis à 1 et vous vous déplacez ensuite à gauche dans le bit de signe.

Changer ceci en ~ 0u empêche UB mais imprime le même résultat, la question est donc de savoir pourquoi.

unsigned char c = (~0 << 3);

0xfe

0x1ffe

(((~0 << 3) >> 4) << 1)

0x0fff

((~0 << 3) >> 4)

0xfff8

`~0u << 3`

0xffff

J'ai compilé (avec x86-64 gcc 9.1 ) ces deux lignes:

main:
        push    rbp
        mov     rbp, rsp
        mov     BYTE PTR [rbp-1], -2
        mov     BYTE PTR [rbp-2], -2
        mov     eax, 0
        pop     rbp
        ret

Et j'ai obtenu la sortie d'assembly suivante:

int main() {
    unsigned char e=(~0 << 1);

    unsigned char d=(((~0 << 3) >> 4) << 1);
}

Comme vous pouvez le voir, les deux lignes sont converties dans la même instruction mov BYTE PTR [rbp-1], -2 . Donc, il semble que le compilateur effectue une optimisation avec votre premier code.

Merci à Thomas Jager pour sa réponse (donnée sur le commentaire de la question)

La solution est simple.

Dans le 1er code, la manipulation des bits est effectuée en prenant l'opérande comme char signé. Pour cette raison, deux nombres binaires complémentaires continuent de changer leur modèle de bits pendant que la manipulation de bits est en cours. Après cela, le nombre de complément à deux résultats est converti en nombre positif avant d'être affecté à la variable non signée c. Le résultat est donc finalement 254.

La question est d'expliquer pourquoi deux sorties de code sont différentes. Nous savons tous que Code 2nd fonctionne bien. Par conséquent, je n'explique que pourquoi le code 1 ne fonctionne pas correctement.

1er code: -

Step 1:   ~0 -----> -1 ----(binary form)----> 11111111 with sign bit 1 (means negative)


Step 2:   (sign bit 1)11111111 << 3 -----shifting to left----> (sign bit 1)11111000


Step 3 ***:   (sign bit 1)11111000 >> 4 ----shifing to right-----> (sign bit 1)11111111

*[*** - The left most bits is 1 in Result because of sign extension 
     Sign bit 1 retain its bit to 1 but right shifting the number will append 1 to 
left most bits without modify sign bit to 0 . 
     Hence all left most bit append to 1 because sign bit 1 is supplying this 1 to 
left most bits while right shifting                                          ]*


Step 4:    (sign bit 1)11111111 << 1 ---shifting to left---> (sign bit 1)11111110


Step 5:    two complement number (sign bit 1)11111110 converted to positive number 
            by deleting only sign bit to 0.


Step 6:    Result : (sign bit 0)11111110 ---decimal equivalent---> 254

Le traçage du 1er code est le suivant: - p >

unsigned char c=(((~0 << 3) >> 4) << 1);
printf("%d", c);

Je viens d'expliquer sa réponse.

Merci à tous d'avoir fait l'effort de répondre à cette question.