ça voudrait dire que le compilateur génère automatiquement des opérations qui masquent 8 des 16 bits
ah... ça y est, j'ai ma lumière éclairée.
Effectivement, rien ne semble interdire en pratique de stocker plus gros tant que 255+1 donne 0... J'avais mis une contrainte qui n'est sans dont pas dans la spec, celle que ce soit une seule opération, "uint8_t fait exactement 8 bit" est peut-être "uint8_t doit se comporter comme si il fait exactement 8 bit" et dans ce cas la ma conclusion n'est plus bonne.
Mais du coup :
Moi ce que j'ai retenu de la norme c'est que int8_t peut ne pas être défini si jamais ton architecture ne permet pas d'adresser les choses par mots de 8 bits.
semble faux puisque dans ce que tu dis à peut être 16 bits, du moment où le résultat est comme 8 bits.
[^] # Re: Question probablement bête
Posté par Zenitram (site web personnel) . En réponse au journal #define CHAR_BIT 8. Évalué à 1. Dernière modification le 20 octobre 2024 à 21:46.
ah... ça y est, j'ai ma lumière éclairée.
Effectivement, rien ne semble interdire en pratique de stocker plus gros tant que 255+1 donne 0... J'avais mis une contrainte qui n'est sans dont pas dans la spec, celle que ce soit une seule opération, "uint8_t fait exactement 8 bit" est peut-être "uint8_t doit se comporter comme si il fait exactement 8 bit" et dans ce cas la ma conclusion n'est plus bonne.
Mais du coup :
semble faux puisque dans ce que tu dis à peut être 16 bits, du moment où le résultat est comme 8 bits.