Bonjour chers vous,

La question est simple. On considère le programme C suivant.

1. include <stdio.h>

int main()
{
    int a[5] = {1,2,3,4,5};
    int *ptr = (int *)((long)a+1);
    printf("%d\n", *ptr);
    return 0;
}

Quel nombre va être affiché à l'écran à l'exécution de ce programme ?

Merci d'essayer de jouer le jeu, c'est à dire de proposer une réponse avant d'éxectuer le programme.

Ça dépends de la taille d'un int sur le compilateur aussi.

Je suppose x86-64 compile avec gcc. int fait 32 bit, long fait 64, int* fait 64.

Je predis "131072"
Explication:
La conversion en long est equivalente a une conversion en char*, ca decale la lecture d'un octet. Rappelons que l'architecture intel stocke la memoire par pair d'octet en big-endian par d'octet stocke en little-endian.
La memoire ressemble a ca en hexa: |0001 0000 |0002 0000|
quand on rajoute 1 a a, on obtient une memoire decalee comme ca
00 | 01 0000 00|02 0000

et le nombre 0100 0000 en hexa c'est 131072

notons que les lectur memoire non aligne ne marche pas sur plein d'architecture et sont plus lent sur processeur x86.

• • ********************

je compile... j'ai perdu...

" Je suppose x86-64 compile avec gcc. int fait 32 bit, long fait 64, int* fait 64. "

Mais en fait ça n'a aucune importance la taille du int finalement, c'est juste que j'avais cru voir un * là où il n'y en avait pas et où ça aurait eu de l'importance.

En vrai, mon explication n'est pas coherente. Je pensais lire "| 01 0000 00|" en memoire, ce qui est "0000 0100" en hexa. ce qui devrait etre 256... Mais c'est pas ca non plus... J'ai loupe quelquechose...

Pour info, j'avais prédis 256, ce qui n'est pas la réponse que ma machine me donne.

...stupid architecture...stupid addressing modes...

5 ?

perdu!

J'ai pensé 256, mais... non.

Maintenant, même en ayant vu la réponse et en réfléchissant, je vois pas d'où sort ce nombre, ça me paraît totalement illogique

Y'a l'explication ?

x86 c'est pas little endian... c'est pas big endian non plus...

" x86 c'est pas little endian... c'est pas big endian non plus... "

L'histoire c'est que hexdump m'a menti la semaine derniere. En memoire les donnee sont little-endian par octet, big-endian sur les octets. (alors que je pensais que c'etait par pair d'octet)

Donc en memoire c'est comme ca: |0100 0000 |0200 0000|

Quand tu fais a+1, tu te retrouves avec: 00 0000 02|00 0000 ...

0000 0002 en x86 c'est equivalent a 0200 0000 en humain base 16

La conversion base 16-> base 10 est laisse en exercice au lecteur.

Personne ne sait ca ? x86 ca stocke les entiers bizarres.
Si un entier 64 bit en hexa est: "ab cd ef gh ij kl mn op". Il est stocke en memoire "op mn kl ij gh ef cd ab". Et du coup, c'est le merdier...

J'avais tenté d'écrire du texte avec des int :

http://codepad.org/WDYdmiKJ

Chaque lettre (chaque octet autrement dit) est rentrée à l'envers.

Wikipedia [1] m'aide a preciser ma pense

x86 est little endian avec un sous composant par octet en big endian. Typiquement powerpc est big endian avec un sous composant par bit big endian.

Ce qui fait que si tu ecris des donnees binaire avec un powerpc, et que tu les lis sur x86, tu dois inverser les octets au sein d'un mot, mais pas les bit au sein d'un octet.

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

Oui voila c'est bien ça.

Ah bah oui, tout s'explique.
J'avais oublié que les octets étaient à l'envers...

Merci pour l'explication

Pas mal ! ca permet de revoir les bases ! posts en plus souvent ;)

041: je me sens moins seul avec mon 256.