pourquoi tu ne peux pas changer un uint16_t

Vous pouvez décaler un uint16_t . Ce que vous ne pouvez pas faire, c'est décaler une valeur entière d'un nombre supérieur ou égal à la taille du type. Cela provoque le comportement indéfini . Ceci est documenté dans la section 6.5.7p3 du C standard concernant les opérateurs de décalage au niveau du bit:

Les promotions entières sont effectuées sur chacun des opérandes. le le type du résultat est celui de l'opérande gauche promu. Si la valeur de l'opérande de droite est négative ou est supérieure à ou égal à la largeur de l'opérande gauche promu, le comportement est indéfini.

On pourrait penser que cela signifie que tout décalage supérieur ou égal à 16 sur un uint16_t n'est pas valide. Cependant , comme mentionné ci-dessus, les opérandes de l'opérateur font l'objet d'une promotion d'entiers . Cela signifie que toute valeur avec un rang inférieur à int est promue en int avant d'être utilisée dans une expression. Donc, si int est de 32 bits sur votre système, alors vous pouvez décaler jusqu'à 31 bits à gauche.

C'est pourquoi (byte3 ne génère pas d'avertissement même si byte est un uint8_t tandis que (hword0 ne l'est pas. Cependant, il y a toujours un problème ici en raison de la promotion vers int . Étant donné que la valeur promue est maintenant signée, vous courez le risque de déplacer un 1 dans le bit de signe. Cela appelle également un comportement non défini.

Pour résoudre ce problème, toute valeur décalée vers la gauche de 32 ou plus doit d'abord être transtypée en uint64_t afin que la valeur puisse être appliquée correctement, ainsi que toute valeur qui peut finir par déplacer un 1 dans le bit de signe:

 uint64_t result = ( (uint64_t)hword0 << 32 ) + 
    ( (uint64_t)byte3 << 24 ) + ( (uint64_t)byte2 << 16 ) + 
    ( (uint64_t)byte1 << 8  ) + ( byte0 << 0  );

Pour faire ce que vous voulez faire, l'idée clé est d'utiliser un uint64_t intermédiaire (la taille finale) dans lequel mélanger les bits.

Les compilations suivantes sans avertissements:

vous pouvez utiliser la promotion automatique (et aucune diffusion)

//           vvvvvvvv ---- formal parameter
uint64_t sc (uint64_t ui64) {
  return static_cast<uint64_t>(ui64);
}


     // using static cast function
     {
        uint64_t result = (
           (sc(hword0) << 32) |
           (sc(byte3)  << 24) |
           (sc(byte2)  << 16) |
           (sc(byte1)  <<  8) |
           (sc(byte0)  <<  0)
           );

        cout << "\n  " << hex << result << endl;
     }

vous pouvez également utiliser la diffusion statique (plusieurs times):

     {
        uint64_t result = (
           (static_cast<uint64_t>(hword0) << 32) |
           (static_cast<uint64_t>(byte3)  << 24) |
           (static_cast<uint64_t>(byte2)  << 16) |
           (static_cast<uint64_t>(byte1)  <<  8) |
           (static_cast<uint64_t>(byte0)  << 0 )
           );

        cout << "\n  " << hex << result << endl;
     }

Et vous pouvez faire les deux en créant une fonction pour a) effectuer le cast statique et b) avec un paramètre formel pour que le compilateur effectue une promotion automatique.

La fonction ressemble à:

     {
        uint64_t b4567 = hword0; // auto promotion
        uint64_t b3    = byte3;
        uint64_t b2    = byte2;
        uint64_t b1    = byte1;
        uint64_t b0    = byte0;

        uint64_t result =  (
           (b4567 << 32) |
           (b3    << 24) |
           (b2    << 16) |
           (b1    <<  8) |
           (b0    <<  0)   );
     }

Du point de vue C:

De nombreuses discussions ici omettent qu'un uint8_t appliqué à un quart de travail (gauche ou droite) est d'abord promu en int , puis les règles de décalage sont appliquées.

La même chose se produit avec uint16_t lorsque int est 32 bits. (17 bits ou plus)

Lorsque int est 32 bits

hword0 est UB due à la quantité de décalage trop grande: en dehors de 0 à 31.
byte3 est UB lors d'une tentative de passage dans le bit de signe . byte3 & 0x80 est vrai.

Les autres décalages sont OK.

Si int était 64 bits, OP le code d'origine est correct - pas d'UB, y compris hword0 .

Si int avait été 16 bits, tous les décalages du code ( à part ) sont UB ou UB potentiel.

Pour ce faire, sans lancer (quelque chose que j'essaie d'éviter), prendre en compte

uint64_t result = (1ull*hword0 << 32) + (1ul*byte3 << 24) + (1ul*byte2 << 16) +
    (1u*byte1 << 8) + byte0;

Ou

// uint64_t result = (hword0 << 32) + (byte3 << 24) + (byte2 << 16) + (byte1 << 8) + byte0

// Let an optimizing compiler do its job
uint64_t result = hword0;
result <<= 8;
result += byte3;
result <<= 8;
result += byte2;
result <<= 8;
result += byte1;
result <<= 8;
result += byte0;