Au début, je voulais poser une question, mais finalement, je pense avoir trouvé, alors je voulais vous faire part de cette bizarrerie.

Voici un petit code :

char test = 0xA0;
....
test = test >> 4;

Avec mon collegue (oui, c´est au boulot qu´on vient de se casser la tete avec ça) on était sur qu´on aurait 0x0A dans test.

Quelle ne fut pas notre surprise, quand, en débuggant, nous avons vu : 0xFA dans le résultat !! !

Voici l´explication (hypothese) que l´on a :
la variable test et est chargée dans le registre EAX du processeur. Comme c´est un char, seul AL est mis a jour (le registre de poids faible du registre 32 bits EAX)

du coup, les autres octets de EAX ne sont pas touchés.

est basé sur des int.

de ce fait, c´est tout EAX qui est shifté.
Le F qui apparait vient donc du 2e octet de EAX qui n´était pas nul (du a une opération précédente)

Un sacré piege qui nous a bien étonné...
Avez vous déja eu ça ?

et zut, mon titre est faux, c´est SHIFT RIGHT...
Pas grave...

non, je n´ai jamais eu ca, et je penses d´ailleurs que ce n´est pas normal...

• si si, c´est tout a fait normal.

Tu aura le comportement voulu en utilisant des unsigned char à la place de char (enfin je crois).

Mais l´opérateur >> préserve le signe des quantités signées, c´est à dire que le bit de signe (celui de poids le plus fort) n´est pas modifié par l´opérateur. Contrairement à l´opérateur << qui mets toujours à 0 le bit de poids le plus faible.

comme 0xA0=0b10100000 en le décalant (car l´opérateur est bien défini pour tout les entiers (peut-être pas à 64 bits cela dit sur une machine 30 bits)), le 1 à gauche est préservé.

je précise que ce que j´ai dit est valable en C++. En C (d´après le sujet du message), c´est peut-être différent, mais je n´en sais rien.

je confirme, et au passage, notons que certains langages permettent la distinction ; i.e. SHR/SHL Vs. SAR/SAL en assembleur x86, << et >> Vs. <<< et >>> dans d´autres langages plus haut niveau, etc.