Tipo de advertencia de conversión después de operaciones bit a bit en C

Question

¿Cómo explica que la línea 7 reciba una advertencia, pero no la línea 5 o la línea 6?

int main() 
{ 
    unsigned char a = 0xFF; 
    unsigned char b = 0xFF; 
    a = a | b;      // 5: (no warning) 
    a = (unsigned char)(b & 0xF);  // 6: (no warning) 
    a = a | (unsigned char)(b & 0xF); // 7: (warning) 
    return 0; 
} 

GCC 4.6.2 de salida cuando se compila en una arquitectura de 32 bits (PC con Windows):

gcc -c main.c --std=c89 -Wall -Wextra -Wconversion -pedantic 
main.c: In function 'main': 
main.c:7:11: warning: conversion to 'unsigned char' from 'int' may alter its value [-Wconversion] 

Si esto ayuda a entender mi pregunta, aquí es cómo veo esto (probablemente incorrecta!) :

Supongo que en una máquina de 32 bits las operaciones se realizan en números de 32 bits. Dado que unsigned char cabe en 32-bit int, el resultado de la operación es 32-bit int. Pero desde GCC no da advertencias en las líneas 5 y 6, supongo que hay algo más en juego:

línea 5: GCC cifras que (UCHAR) O (UCHAR) nunca es mayor que MAX (UCHAR) , entonces no hay advertencia.

línea 6: GCC calcula que (uchar) Y 0xF nunca es mayor que MAX (uchar), entonces no hay advertencia. El lanzamiento explícito ni siquiera es necesario.

línea 7: Según las suposiciones anteriores: Y no debe dar aviso (ya que la línea 6), O tampoco debe dar aviso (desde la línea 5).

Supongo que mi lógica está defectuosa en algún lugar allí. Ayúdame a entender la lógica del compilador.

Answer 1

Uso linux x86_64, GCC 4.70. Y obtén el mismo error Compilo el código y uso gdb para desensamblar el archivo de ejecución. Esto es lo que obtengo

(gdb) l 
1 int main(){ 
2  unsigned char a = 0xff; 
3  unsigned char b = 0xff; 
4  a = a | b; 
5  a = (unsigned char)(b & 0xf); 
6  a |= (unsigned char)(b & 0xf); 
7  return 0; 
8 } 
(gdb) b 4 
Breakpoint 1 at 0x4004a8: file test.c, line 4. 
(gdb) b 5 
Breakpoint 2 at 0x4004af: file test.c, line 5. 
(gdb) b 6 
Breakpoint 3 at 0x4004b9: file test.c, line 6. 
(gdb) r 
Starting program: /home/spyder/stackoverflow/a.out 

Breakpoint 1, main() at test.c:4 
4  a = a | b; 
(gdb) disassemble 
Dump of assembler code for function main: 
    0x000000000040049c <+0>: push %rbp 
    0x000000000040049d <+1>: mov %rsp,%rbp 
    0x00000000004004a0 <+4>: movb $0xff,-0x1(%rbp) 
    0x00000000004004a4 <+8>: movb $0xff,-0x2(%rbp) 
=> 0x00000000004004a8 <+12>: movzbl -0x2(%rbp),%eax 
    0x00000000004004ac <+16>: or  %al,-0x1(%rbp) 
    0x00000000004004af <+19>: movzbl -0x2(%rbp),%eax 
    0x00000000004004b3 <+23>: and $0xf,%eax 
    0x00000000004004b6 <+26>: mov %al,-0x1(%rbp) 
    0x00000000004004b9 <+29>: movzbl -0x2(%rbp),%eax 
    0x00000000004004bd <+33>: mov %eax,%edx 
    0x00000000004004bf <+35>: and $0xf,%edx 
    0x00000000004004c2 <+38>: movzbl -0x1(%rbp),%eax 
    0x00000000004004c6 <+42>: or  %edx,%eax 
    0x00000000004004c8 <+44>: mov %al,-0x1(%rbp) 
    0x00000000004004cb <+47>: mov $0x0,%eax 
    0x00000000004004d0 <+52>: pop %rbp 
    0x00000000004004d1 <+53>: retq 
End of assembler dump. 

la a = a | b se compila para

movzbl -0x2(%rbp),%eax 
or  %al,-0x1(%rbp) 

la a = (unsigned char)(b & 0xf) se compila para

mov %al,-0x2(%rbp) 
and $0xf,%eax 
mov %al,-0x1(%rbp) 

la a |= (unsigned char)(b & 0xf); se compila para

movzbl -0x2(%rbp),%eax 
mov %eax,%edx 
and $0xf,%edx 
movzbl -0x1(%rbp),%eax 
or  %edx,%eax 
mov %al,-0x1(%rbp) 

el lanzamiento explicto no apareció en el código asm. El problema es cuando se realiza la operación (b & 0xf). la salida de la operación es sizeof(int). lo que debe utilizar en su lugar:

a = (unsigned char)(a | (b & 0xF)); 

PS: fundido explict no puedan generar ninguna advertencia. incluso perderás algo.

Answer 2

Creo que el problema es que convierte int a unsigned char, Y de vuelta a int.

La línea 6 convierte int en unsigned char, pero solo la almacena en unsigned char.
La línea 7 convierte int en unsigned char, y luego, para hacer aritmética, la convierte nuevamente en int.El nuevo entero puede ser diferente del original, por lo que recibe una advertencia.

Answer 3

El tipo de retorno del operador bit a bit & es entero. Siempre que inserte un int (4 bytes) en char o char sin signo (1 byte), se le advierte.

Por lo tanto, esto no está relacionado con el operador bit a bit y está relacionado con el tipo de transmisión de variable de 4 bytes a variable de 1 byte.

Answer 4

Los compiladores son creados por personas y no tienen tiempo infinito para descubrir todas las posibilidades aritméticas para decidir, en cuyo caso vale la pena emitir una advertencia.

por lo que creo (opinión atención) que los ingenieros del compilador iría de la siguiente manera:

• general, emitir una advertencia si el código se ve como si pudiera estar equivocado.
• encuentra todos los casos obvios donde se puede corregir el compilador para que funcione con facilidad.
• deje el resto de las advertencias como falsos positivos, porque la persona sabe lo que hace o se sentirá aliviado de que el compilador advierta.

Esperaría que las personas escriban código donde el resultado se convierte en (unsigned char) o donde el operador más externo enmascara todos los bytes más altos con una constante.

• a = (unsigned char) (/* some obscure bit-wise expressoin */); estaría bien entonces
• a = 0xff & (/* some obscure bit-wise expressoin */); también está bien

si sabe que su compilador traduce esos dos patrones correctamente los demás casos no debería molestarle demasiado.

que he visto compiladores que emitiría una advertencia debido a = a | b; por lo GCC no dar una advertencia es un bono gratis. podría ser, que gcc simplemente infiere la asignación constante en a | b y por lo tanto lo reemplaza con 0xff | 0xff que se sabe que funciona sin problemas. Si eso sucede, no sé por qué no puede derivar el valor constante de a en las otras declaraciones.