Je dirais que ça affiche un nombre maintenant je réfléchis pour savoir lequel

Je pense que ça affiche 16 mais je ne suis pas sur
Un entier fait 4 bytes et un char fait 1 byte si je ne me trompe pas donc quand on donne la référence de p dans le pointeur de char, celui-ci ne prend que les 8 premiers bits et donc : 272 en binaire = 100010000 donc si on ne prend que les 8 premiers bits cela nous donne 00010000 donc 16 en décimal
Correcte ?

c'est merdique ces trucs la... l'architecture x86 est bizarre dans sa representation des nombres en memoire (big endian/little endian). Je ne serais pas etonne si la reponse etait 0, ou bien 8.

Grunt, je me suis encore fait avoir par les saloperies de x86. 0 serait sur une architecture raisonnable comme MIPS ou ARM.

Tu peux expliquer pourquoi ça ferait 0 sur ARM ?

Je vois la logique du 16 mais pas celle du 0.

Parceque ca depend de l'ordre des octets en memoire: endianness[1]. le code de aldebran, lis le premier octets de l'entier.

x86 est little-endian par octet. Il stocke le nombre en memoire comme ceci:
0001 0000 | 0000 0001 | 0000 0000 | 0000 0000
Donc le resultat en sortie est "0001 0000" soit 16

ARM est big-endian (par octet). Il stocke le nombre en memoire:
0000 0000 | 0000 0000 | 0000 0001 | 0001 0000
Donc le resultat en sortie est "0000 0000" soit 0.

C'est un probleme d'endianness des processeurs.

Notons, que wikipedia indique que ARM est maintenant un processeur bi-endian, c'est a dire qu'il supporte les operations little endian et big-endian. mais un processeur POWER de IBM ou motorola, sont big endian.

[1] http://en.wikipedia.org/wiki/Endianness

Ah ben oui tout simplement ^^

Je ne l'ai pas précisé mais oui c'était bien 16 donc si quelqu'un d'autre veut poser une devinette, la place est libre

Que va afficher ce code en fonction de n?
http://pastebin.com/ZaDcH3Yq

Un peu plus dur, qu'est ce que ca affiche si on remplace le code de la condition du if ligne 15 par celui de la ligne commentée juste au dessus?