Interpretando valores hexadecimales?

Question

Esto podría ser muy básico o incluso tonto para los expertos aquí, pero quería entender esto. La mayoría de las veces que generalmente escribir valores hexadecimales como esta en C:

unsigned int a = 0xFFFF1232; 

Digamos que estoy tratando de extraer los primeros y los últimos 16 bits entonces puedo simplemente hacer:

unsigned short high = a >> 16; // Gives me 0xFFFF 
unsigned short low = a & 0x0000FFFF; // Gives me 0x000which is then stored as 0x1232 

En algunos del código que estoy leyendo me he encontrado lo siguiente:

unsigned short high = a >> 16; 
unsigned short low = a & 0xFFFF; 

tengo dos preguntas

• Cuando está AND ing un valor de 32 bits con una máscara, ¿por qué las personas escriben 0xFFFF en lugar de 0x0000FFFF? ¿Es para mantenerlo compacto?
• ¿Es siempre seguro escribir 0x0000FFFF como 0xFFFF? ¿Se interpreta de manera diferente en cualquier contexto?

Answer 1

Son completamente sinónimos. Dejar los ceros a la izquierda lo hace un poco más legible.

Answer 2

En su ejemplo low es un short (normalmente 16 bits). Por lo tanto, los ceros iniciales no solo son redundantes, sino que sugieren que se espera un resultado de 32 bits, y en este caso los bits superiores se descartan, por lo que podría aclarar la intención del código.

De hecho, en este caso

unsigned short low = a ; 

sería suficiente, aunque es tal vez menos claro.

Además no se debe asumir que los anchos enteros son apropiados y utilizar los <stdint.h> tipos vez:

uint32_t a = 0xFFFF1232; 
uint16_t = a >> 16; 
uint16_t = a & 0xFFFF; 

Si está utilizando VC++ que no alimente ese encabezado, puede utilizar this implementation

Answer 3

Ellos Son identicos.

Y, supongo que siempre tienen 32 bits de longitud. Si tu plataforma pasó a usar ints de 64 bits, ¿lo escribirías así?

unsigned short low = a & 0x000000000000FFFF; // ouch. Did I count them right? 

Y hay otra razón por la que no debe perder tiempo en poner en ceros a la izquierda: Vas a tratar de hacer con decimales siguiente, que es una mala idea:

int x = 00000377 

printf("%d\n", x); // 255! WTF.... 

Answer 4

Algo así como 0x1 se llama literal, que por defecto es un tipo int. Esto no es necesariamente 32 bits, dependiendo del compilador o plataforma, así que sí, hay un contexto en el que no es seguro dejar los ceros a la izquierda.

Por ejemplo, en los sistemas embebidos, es común encontrar tipos de int que tienen solo 16 bits de longitud. Si quieres un número entero más largo, necesitas usar int largo.

En ese caso, el compilador se dará cuenta si olvidó agregar "L" al literal hexadecimal, para indicar que desea el tipo más largo.

unsigned int a = 0xFFFF1234; 

sería un error de compilación en el mejor, o un error no detectado en el peor. Necesitaría usar

unsigned long int a = 0xFFFF1234L; 

en su lugar.

Answer 5

En su caso, 0x0000FFFF y 0xFFFF son idénticos.

Esto no sería el caso si sus variables no estuvieran sin firmar: un valor de 16 bits de 0xFFFF significa -1, que es 0xFFFFFFFF en 32 bits.