2009-08-17 4 views
2

J'ai un pointeur UINT8 qui reçoit des informations via un casting * (UINT16 *). EG:La valeur UINT16 semble être "à l'envers" lors de l'impression

int offset = someValue; 
UINT16 mUINT16 = 0xAAFF 
*(UINT16 *)&mArray[offset] = mUINT16; 

for(int i = 0; i < mArrayLength; i++) 
{ 
    printf("%02X",*(mArray + i)); 
} 

output: ... FF AA ... 
expected: ... AA FF ... 

La valeur que je me attends à imprimer quand il atteint décalage doit être AA FF, mais la valeur qui est imprimé est FF AA, et pour la vie de moi je ne peux pas comprendre pourquoi .

+0

L'une des deux réponses existantes que je publie ceci est faux ..... –

Répondre

9

Vous utilisez une petite machine d'endian.

2

C'est parce que le processeur de votre ordinateur utilise la représentation little endian des entiers dans la mémoire

+0

Je pense que vous voulez dire petit endian. Cela produirait le danulepk attendu sur une machine big-endian. –

+0

ouais, j'ai eu un petit clavier-content .. J'ai corrigé le post, mais la raison est toujours la même: et le problème d'enadianness –

+1

FWIW, l'endianness n'est pas un attribut de l'OS mais du processeur matériel. Les processeurs de famille x86 sont tous peu endian. Les processeurs OTOH bien pensés tels que la vieille famille 68K sont big-endian. :) –

4

Vous n'avez pas spécifié, mais je devine votre Marray est un tableau d'octets au lieu d'un tableau de UINT16s. Vous utilisez également une machine little-endian. Sur les petites machines d'endian, les octets sont stockés dans l'ordre inverse des machines big-endian. Les grands endos les stockent à peu près comme les humains les lisent.

4

Vous utilisez probablement un ordinateur qui utilise une représentation "little-endian" des nombres dans la mémoire (telle que l'architecture Intel x86). Fondamentalement, cela signifie que le octet le moins significatif de toute valeur sera stocké à l'adresse la plus basse de l'emplacement de mémoire qui est utilisé pour stocker les valeurs. See Wikipdia for details.

Dans votre cas, le nombre 0xAAFF est constitué des deux octets 0xAA et 0xFF avec 0xFF étant le moins significatif. Par conséquent, une machine little-endian stockera 0xFF à l'adresse la plus basse, puis 0xAA. Par conséquent, si vous interprétez l'emplacement mémoire dans lequel vous avez écrit une valeur UINT16 comme UINT8, vous obtiendrez l'octet écrit à cet emplacement qui se trouve être 0xFF

Si vous souhaitez écrire un tableau de valeurs UINT16 dans un de façon appropriée tableau des valeurs de taille uint8 telle que la sortie correspondra à vos attentes que vous pourriez le faire de la manière suivante:

/* copy inItems UINT16 values from inArray to outArray in 
* MSB first (big-endian) order 
*/ 
void copyBigEndianArray(UINT16 *inArray, size_t inItems, UINT8 *outArray) 
{ 
    for (int i = 0; i < inItems; i++) 
    { 
     // shift one byte right: AAFF -> 00AA 
     outArray[2*i]  = inArray[i] >> 8; 

     // cut off left byte in conversion: AAFF -> FF 
     outArray[2*i + 1] = inArray[i]  
    } 
} 

vous pouvez également consulter la hton*/ntoh*-family of functions si elles sont disponibles sur votre plate-forme.

Questions connexes