Comportement étrange d'uint8_t sur un iostream - Page 1

Merci de m'éclairer, je comprends plus rien.

Un u32: 32 bits = 4 * 1 byte
donc un byte = 8bits = (u)int8_t

Alors quelqu'un peut m'expliquer le résultat de ceci?

http://ideone.com/RG3yxK

Pourquoi quand je passe par std::cout, seuls les 4 premiers bits sont gérés dans mon byte? par printf, tout est normal...
#include <iostream> #include <cstdint> #include <bitset> int main() { uint32_t x = 0x0FFFFE35; std::cout << std::bitset<32>(x) << " " << std::bitset<8>(((int8_t)x)); std::cout << std::endl; std::cout << std::hex << x << " " << std::hex << uint8_t(x & 0xFF); std::cout << std::endl; std::cout << std::hex << x << " " << std::hex << (x & 0xFF); uint8_t byte = 0x35; printf("\nvia printf: %X\n", byte); std::cout << std::hex << x << " " << std::hex << byte; return 0; }

Pour std::cout je sais pas, je m'en sers pas.

Par contre, ce que tu fais avec printf() n'est pas valide : l'argument de %X doit être un unsigned int, et il faut un cast explicite car printf() a un nombre d'arguments variables dont le type n'est pas connu à l'avance. Par coup de pot, ça fonctionne quand même sans sur x86, mais ça déconne sur d'autres architectures.

Je ne me sers pas de printf en général, c'était un test; je pense (sans avoir regardé le vaudou derrière printf, aka parsing du format pour déterminer les types) que mon uint8_t (aka unsigned char sur la plupart des platformes) est simplement cast implicitement sur un unsigned int. (sur x86)

Je trouve juste bizarre que std::cout ne lise que les 4 premiers bits (ou du moins, en ait l'air) d'un byte, qui est par définition sur 8 bits... Soit je me suis planté quelque part de façon tellement évidente que je ne vois pas mon erreur, soit y a un bug quelque part (et ça me surprendrait qu'un tel bug n'aurait pas été déjà trouvé et signalé)

printf("\nvia printf: %X\n", (unsigned int)(byte)); écrit bien 35, mais c'est normal, on étend à 32 bits.

T'est sûr que << fonctionne avec des chars ? http://www.cplusplus.com/reference/ostream/ostream/operator%3C%3C/
Et lis en bas, je sais pas si dans ton cas t'as pas une interférence à cause de l'emploi du printf. Mais je suis pas un pro du C++, je raconte probablement de la merde.

Tu parles des Data race ? C'est uniquement un problème sur du multithread, c'est du single là.

Bon point pour operator<<, j'avais pas pensé à vérifer, . basic_ostream& operator<<( unsigned char value ); n'est pas défini.

[EDIT] OK, j'ai calé.
uint8_t byte = 0x35; std::cout << std::hex << x << " " << std::hex << byte;
ffffe35 5
uint8_t byte = 0x35; std::cout << std::hex << x << " " << std::hex << +byte; // Gros hack pour cast implicitement
ffffe35 35

0x35 = 53 = 5 en ASCII.



ça aurait été sûrement plus obvious avec 0x5F :')

Zerosquare (./2) :
Par contre, ce que tu fais avec printf() n'est pas valide : l'argument de %X doit être un unsigned int, et il faut un cast explicite car printf() a un nombre d'arguments variables dont le type n'est pas connu à l'avance. Par coup de pot, ça fonctionne quand même sans sur x86, mais ça déconne sur d'autres architectures.

En C++, je ne sais pas.
En C, c'est valide. Cf §6.5.2.2 de la norme, alinéa 6.

If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions.

Intéressant, je ne connaissais pas ce point. Il me semble bien avoir rencontré un compilateur pour lequel ça ne marchait pas sans le cast, mais peut-être qu'il était bugué. Merci PpHd

Tous les compilateurs (et en particuliers ceux dédiés à l'embarqué) ne respectent pas la norme à la lettre (parfois parce que ça n'aurait pas de sens sur le HW... et parfois pas).

Ximoon (./8) :
Tous les compilateurs (et en particuliers ceux dédiés à l'embarqué) ne respectent pas la norme à la lettre (parfois parce que ça n'aurait pas de sens sur le HW... et parfois pas).

Des noms!!!