Version imprimable
Bonjour,
Je cherche à récupérer les octets contenus dans un entier ???
int nombre = 11804;
unsigned char tableauOctets[4];
en sachant que 11804 vaut 0x2b4c en hexa
je voudrais obtenir:
tableauOctets[0] = 0x00
tableauOctets[0] = 0x00
tableauOctets[0] = 0x2b
tableauOctets[0] = 0x4c
Ca parait basique ... :oops:
Merci de me donner un petit coup de main si vous savaez faire ça ;)
Code:
2
3
4
5
6
7
8
9
10
Code:
2
3
4
5
cmoibal,
...ça ne marche pas !!! mais merci quand même ;)
quentind,
... ça marche !!! Merci bien :D
Attention:
- Le code de cmoibal comporte une légère erreur (il faut utiliser l'opérateur >> au lieu de l'opérateur <<), mais est indépendant l'endianness de l'architecture: Son code affichera toujours l'octet de poids le plus faible en premier (little-endian).
- Le code de quentind, lui, est à déconseiller pour la raison opposée: Selon l'endianess de la machine, il affichera l'octet de poids le plus fort en premier (big-endian), ou le plus faible (little-endian).
Et bien sûr, ces deux codes dépendent du fait qu'un int fasse quatre char et qu'un char fasse 8 bits.
:king: MERCI Médinoc pour la correction :king:
Et trés bonne explication .... :D
Salut,
euhh NON en hexa 11804 c'est 0x2E1C ;)Citation:
Envoyé par raphdatcom
@++Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15#define MAXSIZE 4 #define CHARSIZE 8 <...> unsigned int nombre = 11804; unsigned char tableauOctet[MAXSIZE]; size_t i=0; size_t shift=0; while( nombre && i<MAXSIZE ) { nombre>>=shift; tableauOctet[i]=(unsigned char) nombre; shift+=CHARSIZE; i++; }
Ajouter à cela qu'il utilise un int au lieu d'un unsigned, pour peu que le nombre soit négatif, le résultat du décalage à droite est implementation defined.Citation:
Envoyé par Médinoc
De plus, indépendant de l'endianess? quid de l'endianess d'un PDP ? j'ai un doute!
A priori PDP-11 = 'little-endian'Citation:
Envoyé par nicolas.sitbon
- W
endian.h from glibcCitation:
Envoyé par wiztricks
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
Le code basé sur un décalage à droite reste indépendant de l'endianness même sur PDP, car il ne lit pas octet par octet en mémoire.
@ssmario2 : Pourquoi ne pas définir MAXSIZE en tant que sizeof(int) au lieu de 4 hard-codé ?
Et pour CHARSIZE, tu peux utiliser la macro CHAR_BIT (ou CHAR_BITS, je ne sais plus), définie dans <limits.h>
effectivement mais l'autre remarque reste valable.Citation:
Envoyé par Médinoc
@Médinoc : je n'y avais pas pensé :oops: , en effet c'est plus correcte MERCI
P.S : Oui c'est bel et bien CHAR_BIT
C'est ce que les fous du 32 bits appellent 'middle endian'. But d'un point de vue pratique tu as une relation entre l'endianness et la longueur des mots qui designent une adresse. Sur le PDP, ces mots sont 16 bits et 'si on travaille avec cà' middle endian = little endian.Citation:
Envoyé par nicolas.sitbon
Par contre, si on sort de la boite... ie on mappe ces représentations dans un espace d'adressage 32 bits.... on se retrouve a dire 'middle endian'.
Rigolo n'est ce pas?
Mais cela est un mal de tête que nous avions dans les années 80s... Aujourd'hui tout cela est de l'histoire... Alors 'little-endian' modulo le trick sur l'espace d'adressage va très bien...
- W
Sauf que les mac non-intel, et certains gros serveurs sous certains systèmes POSIX, sont toujours en big-endian...
Non, ce n'est pas de l'histoire ancienne.Citation:
Envoyé par wiztricks
Je me sers quotidiennement de machines neuves Unix avec des processeurs SPARC et d'autres x86, et je peux t'assurer que les problèmes de big-endian / little endian doivent être pris en compte pour chaque programme.
Je ne parlais que de l'endianness du PDP-11.Citation:
Envoyé par gangsoleil
- W
Les processeurs embarques ARM utilisent le middle-endian dans certaines conditions, donc ce n'est pas encore a mettre aux oubliettes de l'Histoire...Citation:
Envoyé par wiztricks