funciones - Comportamiento indefinido de las matemáticas de puntero en una matriz de C++

punteros c++ pdf

Question

¿Por qué la salida de este programa es 4 ?

#include <iostream>
int main()
{
short A[] = {1, 2, 3, 4, 5, 6};
std::cout << *(short*)((char*)A + 7) << std::endl;
return 0;
}

Según tengo entendido, en el sistema Little Endian x86, donde char tiene 1 byte y 2 bytes cortos, la salida debería ser 0x0500 , porque los datos en la matriz A son tan bajos en hexadecimal:

01 00 02 00 03 00 04 00 05 00 06 00

Nos movemos desde el principio 7 bytes hacia adelante y luego leemos 2 bytes. ¿Qué me estoy perdiendo?

Answer 1

El programa tiene un comportamiento indefinido debido a lanzar un puntero alineado incorrectamente a (short*) . Esto rompe las reglas en 6.3.2.3 p6 en C11, que no tiene nada que ver con un alias estricto como se afirma en otras respuestas:

Un puntero a un tipo de objeto se puede convertir en un puntero a un tipo de objeto diferente. Si el puntero resultante no está alineado correctamente para el tipo al que se hace referencia, el comportamiento no está definido.

En [expr.static.cast] p13, C ++ dice que convertir el char* no alineado a char* short* da un valor de puntero no especificado, que podría ser un puntero no válido, que no se puede eliminar.

La forma correcta de inspeccionar los bytes es a través de char* no volviendo a short* y pretendiendo que hay un short en una dirección donde no se puede vivir un short .

Answer 2

Estás violando estrictas reglas de alias aquí. No puedes simplemente leer a mitad de camino en un objeto y pretender que es un objeto por sí solo. No se pueden inventar objetos hipotéticos usando compensaciones de bytes como esta. GCC está perfectamente dentro de sus derechos para hacer locuras, como volver atrás en el tiempo y asesinar a Elvis Presley, cuando le entregas tu programa.

Lo que se le permite hacer es inspeccionar y manipular los bytes que conforman un objeto arbitrario, utilizando un char* . Usando ese privilegio:

#include <iostream>
#include <algorithm>
int main()
{
short A[] = {1, 2, 3, 4, 5, 6};
short B;
std::copy(
(char*)A + 7,
(char*)A + 7 + sizeof(short),
(char*)&B
);
std::cout << std::showbase << std::hex << B << std::endl;
}
// Output: 0x500

( demostración en vivo )

Pero no puede simplemente "componer" un objeto no existente en la colección original.

Además, incluso si tiene un compilador al que se le puede decir que ignore este problema (por ejemplo, con el interruptor de -fno-strict-aliasing GCC), el objeto creado no está alineado correctamente para ninguna de las arquitecturas principales actuales. Un short no puede vivir legalmente en esa ubicación de número impar en la memoria ^† , por lo que no puede fingir que hay uno allí. Simplemente no hay forma de evitar cuán indefinido es el comportamiento del código original; de hecho, si pasas GCC el -fsanitize=undefined switch te lo dirá.

_{^† Estoy simplificando un poco.}

Answer 3

Esto es posiblemente un error en GCC.

Primero, debe notarse que su código está invocando un comportamiento indefinido, debido a la violación de las reglas de alias estricto.

Dicho esto, he aquí por qué lo considero un error:

1. La misma expresión, cuando se asigna por primera vez a un short o short * intermedio, provoca el comportamiento esperado. Solo cuando se pasa la expresión directamente como un argumento de función, se manifiesta el comportamiento inesperado.

2. Ocurre incluso cuando se compila con -O0 -fno-strict-aliasing .

Reescribí su código en C para eliminar la posibilidad de cualquier locura de C ++. Su pregunta fue etiquetada c después de todo! pshort función pshort para asegurar que la naturaleza variada printf no estuviera involucrada.

#include <stdio.h>
static void pshort(short val)
{
printf("0x%hx ", val);
}
int main(void)
{
short A[] = {1, 2, 3, 4, 5, 6};
#define EXP ((short*)((char*)A + 7))
short *p = EXP;
short q = *EXP;
pshort(*p);
pshort(q);
pshort(*EXP);
printf("/n");
return 0;
}

Después de compilar con gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2) :

gcc -O0 -fno-strict-aliasing -g -Wall -Werror endian.c

Salida:

0x500 0x500 0x4

Parece que GCC en realidad está generando un código diferente cuando la expresión se usa directamente como un argumento, aunque estoy usando claramente la misma expresión ( EXP ).

Dumping con objdump -Mintel -S --no-show-raw-insn endian :

int main(void)
{
40054d: push rbp
40054e: mov rbp,rsp
400551: sub rsp,0x20
short A[] = {1, 2, 3, 4, 5, 6};
400555: mov WORD PTR [rbp-0x16],0x1
40055b: mov WORD PTR [rbp-0x14],0x2
400561: mov WORD PTR [rbp-0x12],0x3
400567: mov WORD PTR [rbp-0x10],0x4
40056d: mov WORD PTR [rbp-0xe],0x5
400573: mov WORD PTR [rbp-0xc],0x6
#define EXP ((short*)((char*)A + 7))
short *p = EXP;
400579: lea rax,[rbp-0x16] ; [rbp-0x16] is A
40057d: add rax,0x7
400581: mov QWORD PTR [rbp-0x8],rax ; [rbp-0x08] is p
short q = *EXP;
400585: movzx eax,WORD PTR [rbp-0xf] ; [rbp-0xf] is A plus 7 bytes
400589: mov WORD PTR [rbp-0xa],ax ; [rbp-0xa] is q
pshort(*p);
40058d: mov rax,QWORD PTR [rbp-0x8] ; [rbp-0x08] is p
400591: movzx eax,WORD PTR [rax] ; *p
400594: cwde
400595: mov edi,eax
400597: call 400527 <pshort>
pshort(q);
40059c: movsx eax,WORD PTR [rbp-0xa] ; [rbp-0xa] is q
4005a0: mov edi,eax
4005a2: call 400527 <pshort>
pshort(*EXP);
4005a7: movzx eax,WORD PTR [rbp-0x10] ; [rbp-0x10] is A plus 6 bytes ********
4005ab: cwde
4005ac: mov edi,eax
4005ae: call 400527 <pshort>
printf("/n");
4005b3: mov edi,0xa
4005b8: call 400430 <putchar@plt>
return 0;
4005bd: mov eax,0x0
}
4005c2: leave
4005c3: ret

• Obtengo el mismo resultado con GCC 4.9.4 y GCC 5.5.0 de Docker hub