Nota
Isso foi extraído do meu "O que é a regra estrita de alias e por que nos importamos?" escrever.
O que é aliasing estrito?
Em C e C ++, o aliasing tem a ver com quais tipos de expressão temos permissão para acessar valores armazenados. Em C e C ++, o padrão especifica quais tipos de expressão são permitidos para alias quais tipos. O compilador e o otimizador podem assumir que seguimos estritamente as regras de alias, daí o termo regra estrita de alias . Se tentarmos acessar um valor usando um tipo não permitido, ele será classificado como comportamento indefinido ( UB ). Depois de ter um comportamento indefinido, todas as apostas estão desativadas, os resultados do nosso programa não são mais confiáveis.
Infelizmente, com violações estritas de alias, geralmente obtemos os resultados esperados, deixando a possibilidade de que uma versão futura de um compilador com uma nova otimização decida o código que julgávamos válido. Isso é indesejável e é um objetivo que vale a pena entender as regras estritas de alias e como evitar violá-las.
Para entender mais sobre por que nos importamos, discutiremos questões que surgem ao violar regras estritas de aliasing, punição de tipo, já que técnicas comuns usadas na punição de tipo geralmente violam regras estritas de alias e como digitar trocadilho corretamente.
Exemplos preliminares
Vejamos alguns exemplos, depois podemos falar exatamente sobre o que dizem os padrões, examinar alguns exemplos adicionais e ver como evitar aliases estritos e capturar violações que perdemos. Aqui está um exemplo que não deve surpreender ( exemplo ao vivo ):
int x = 10;
int *ip = &x;
std::cout << *ip << "\n";
*ip = 12;
std::cout << x << "\n";
Temos um int * apontando para a memória ocupada por um int e esse é um alias válido. O otimizador deve assumir que as atribuições por meio de ip podem atualizar o valor ocupado por x .
O próximo exemplo mostra um alias que leva a um comportamento indefinido ( exemplo ao vivo ):
int foo( float *f, int *i ) {
*i = 1;
*f = 0.f;
return *i;
}
int main() {
int x = 0;
std::cout << x << "\n"; // Expect 0
x = foo(reinterpret_cast<float*>(&x), &x);
std::cout << x << "\n"; // Expect 0?
}
Na função foo, pegamos um int * e um float * , neste exemplo, chamamos foo e configuramos os dois parâmetros para apontar para o mesmo local de memória que neste exemplo contém um int . Observe que o reinterpret_cast está dizendo ao compilador para tratar a expressão como se tivesse o tipo especificado por seu parâmetro de modelo. Nesse caso, estamos dizendo para tratar a expressão & x como se tivesse o tipo float * . Podemos esperar ingenuamente que o resultado do segundo corte seja 0, mas com a otimização ativada usando -O2, tanto gcc quanto clang produzem o seguinte resultado:
0
1
O que pode não ser esperado, mas é perfeitamente válido, pois invocamos um comportamento indefinido. Um flutuador não pode validamente alias um objeto int . Portanto, o otimizador pode assumir a constante 1 armazenada ao remover a referência i, que será o valor de retorno, pois um armazenamento através de f não pode afetar validamente um objeto int . A inserção do código no Compiler Explorer mostra que é exatamente isso que está acontecendo ( exemplo ao vivo ):
foo(float*, int*): # @foo(float*, int*)
mov dword ptr [rsi], 1
mov dword ptr [rdi], 0
mov eax, 1
ret
O otimizador que usa a Análise de alias baseada em tipo (TBAA) assume que 1 será retornado e move diretamente o valor constante no registro eax, que carrega o valor de retorno. O TBAA usa as regras de idiomas sobre quais tipos têm permissão de alias para otimizar cargas e armazenamentos. Nesse caso, o TBAA sabe que um float não pode alias e int e otimiza a carga de i .
Agora, para o livro de regras
O que exatamente o padrão diz que somos permitidos e não permitidos? O idioma padrão não é simples, portanto, para cada item, tentarei fornecer exemplos de código que demonstram o significado.
O que o padrão C11 diz?
O padrão C11 diz o seguinte na seção 6.5 Expressões, parágrafo 7 :
Um objeto deve ter seu valor armazenado acessado apenas por uma expressão lvalue que possui um dos seguintes tipos: 88)
- um tipo compatível com o tipo efetivo do objeto,
int x = 1;
int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type int which is compatible with int
- uma versão qualificada de um tipo compatível com o tipo efetivo do objeto,
int x = 1;
const int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type const int which is compatible with int
- um tipo que é o tipo assinado ou não assinado correspondente ao tipo efetivo do objeto,
int x = 1;
unsigned int *p = (unsigned int*)&x;
printf("%u\n", *p ); // *p gives us an lvalue expression of type unsigned int which corresponds to
// the effective type of the object
gcc / clang tem uma extensão e também que permite atribuir unsigned int * para int * mesmo que eles não são tipos compatíveis.
- um tipo que é o tipo assinado ou não assinado, correspondente a uma versão qualificada do tipo efetivo do objeto,
int x = 1;
const unsigned int *p = (const unsigned int*)&x;
printf("%u\n", *p ); // *p gives us an lvalue expression of type const unsigned int which is a unsigned type
// that corresponds with to a qualified verison of the effective type of the object
- um tipo agregado ou de união que inclui um dos tipos mencionados acima entre seus membros (incluindo, recursivamente, um membro de uma união subagregada ou contida), ou
struct foo {
int x;
};
void foobar( struct foo *fp, int *ip ); // struct foo is an aggregate that includes int among its members so it can
// can alias with *ip
foo f;
foobar( &f, &f.x );
- um tipo de personagem.
int x = 65;
char *p = (char *)&x;
printf("%c\n", *p ); // *p gives us an lvalue expression of type char which is a character type.
// The results are not portable due to endianness issues.
O que o Draft 17 Draft Standard diz
O rascunho do padrão C ++ 17 na seção [basic.lval], parágrafo 11, diz:
Se um programa tentar acessar o valor armazenado de um objeto por meio de um valor gl gl diferente de um dos seguintes tipos, o comportamento será indefinido: 63
(11.1) - o tipo dinâmico do objeto,
void *p = malloc( sizeof(int) ); // We have allocated storage but not started the lifetime of an object
int *ip = new (p) int{0}; // Placement new changes the dynamic type of the object to int
std::cout << *ip << "\n"; // *ip gives us a glvalue expression of type int which matches the dynamic type
// of the allocated object
(11.2) - uma versão qualificada para cv do tipo dinâmico do objeto,
int x = 1;
const int *cip = &x;
std::cout << *cip << "\n"; // *cip gives us a glvalue expression of type const int which is a cv-qualified
// version of the dynamic type of x
(11.3) - um tipo semelhante (conforme definido em 7.5) ao tipo dinâmico do objeto,
(11.4) - um tipo que é o tipo assinado ou não assinado correspondente ao tipo dinâmico do objeto,
// Both si and ui are signed or unsigned types corresponding to each others dynamic types
// We can see from this godbolt(https://godbolt.org/g/KowGXB) the optimizer assumes aliasing.
signed int foo( signed int &si, unsigned int &ui ) {
si = 1;
ui = 2;
return si;
}
(11.5) - um tipo que é o tipo assinado ou não assinado, correspondente a uma versão qualificada para cv do tipo dinâmico do objeto,
signed int foo( const signed int &si1, int &si2); // Hard to show this one assumes aliasing
(11.6) - um tipo agregado ou de união que inclui um dos tipos mencionados acima entre seus elementos ou membros de dados não estáticos (incluindo, recursivamente, um elemento ou membro de dados não estático de uma união subagregada ou contida),
struct foo {
int x;
};
// Compiler Explorer example(https://godbolt.org/g/z2wJTC) shows aliasing assumption
int foobar( foo &fp, int &ip ) {
fp.x = 1;
ip = 2;
return fp.x;
}
foo f;
foobar( f, f.x );
(11.7) - um tipo que é um tipo de classe base (possivelmente qualificado para cv) do tipo dinâmico do objeto,
struct foo { int x ; };
struct bar : public foo {};
int foobar( foo &f, bar &b ) {
f.x = 1;
b.x = 2;
return f.x;
}
(11.8) - um tipo de caractere, caractere não assinado ou std :: byte.
int foo( std::byte &b, uint32_t &ui ) {
b = static_cast<std::byte>('a');
ui = 0xFFFFFFFF;
return std::to_integer<int>( b ); // b gives us a glvalue expression of type std::byte which can alias
// an object of type uint32_t
}
Vale ressaltar que o caractere assinado não está incluído na lista acima. Essa é uma diferença notável de C, que indica um tipo de caractere .
O que é Type Punning
Chegamos a esse ponto e podemos estar se perguntando: por que queremos usar o apelido? A resposta normalmente é digitar trocadilho , geralmente os métodos usados violam regras estritas de alias.
Às vezes, queremos contornar o sistema de tipos e interpretar um objeto como um tipo diferente. Isso é chamado de punção de tipo , para reinterpretar um segmento de memória como outro tipo. A punção de tipo é útil para tarefas que desejam acessar a representação subjacente de um objeto para visualizar, transportar ou manipular. Áreas típicas que encontramos como punição de tipo sendo usadas são compiladores, serialização, código de rede, etc.
Tradicionalmente, isso é conseguido pegando o endereço do objeto, convertendo-o em um ponteiro do tipo que queremos reinterpretá-lo como e depois acessando o valor, ou seja, usando o alias. Por exemplo:
int x = 1 ;
// In C
float *fp = (float*)&x ; // Not a valid aliasing
// In C++
float *fp = reinterpret_cast<float*>(&x) ; // Not a valid aliasing
printf( "%f\n", *fp ) ;
Como vimos anteriormente, este não é um alias válido, por isso estamos invocando um comportamento indefinido. Mas tradicionalmente os compiladores não tiravam vantagem das regras estritas de alias e esse tipo de código geralmente funcionava; infelizmente, os desenvolvedores se acostumaram a fazer as coisas dessa maneira. Um método alternativo comum para punição de tipo é por meio de uniões, que são válidas em C, mas com comportamento indefinido em C ++ ( veja o exemplo ao vivo ):
union u1
{
int n;
float f;
} ;
union u1 u;
u.f = 1.0f;
printf( "%d\n”, u.n ); // UB in C++ n is not the active member
Isso não é válido em C ++ e alguns consideram que o objetivo das uniões é unicamente para implementar tipos de variantes e consideram que o uso de uniões para punção de tipo é um abuso.
Como digitamos o trocadilho corretamente?
O método padrão para punção de tipo em C e C ++ é memcpy . Isso pode parecer um pouco pesado, mas o otimizador deve reconhecer o uso do memcpy para punções de tipo, otimizá-lo e gerar um registro para registrar a movimentação. Por exemplo, se sabemos que int64_t tem o mesmo tamanho que o dobro :
static_assert( sizeof( double ) == sizeof( int64_t ) ); // C++17 does not require a message
podemos usar o memcpy :
void func1( double d ) {
std::int64_t n;
std::memcpy(&n, &d, sizeof d);
//...
Em um nível de otimização suficiente, qualquer compilador moderno decente gera código idêntico ao método reinterpret_cast ou método de união mencionado anteriormente para punção de tipo . Examinando o código gerado, vemos que ele usa apenas registre mov (exemplo ao vivo do Compiler Explorer ).
C ++ 20 e bit_cast
No C ++ 20, podemos obter bit_cast ( implementação disponível no link da proposta ), que fornece uma maneira simples e segura de digitar trocadilhos, além de ser utilizável em um contexto constexpr.
A seguir, é apresentado um exemplo de como usar bit_cast para digitar pun um int não assinado a flutuar ( veja ao vivo ):
std::cout << bit_cast<float>(0x447a0000) << "\n" ; //assuming sizeof(float) == sizeof(unsigned int)
No caso em que os tipos Para e De não têm o mesmo tamanho, é necessário usar uma estrutura intermediária15. Usaremos uma estrutura que contém uma matriz de caracteres sizeof (int não assinada) ( assume int não assinada de 4 bytes ) como o tipo From e int sem assinatura como o tipo To . :
struct uint_chars {
unsigned char arr[sizeof( unsigned int )] = {} ; // Assume sizeof( unsigned int ) == 4
};
// Assume len is a multiple of 4
int bar( unsigned char *p, size_t len ) {
int result = 0;
for( size_t index = 0; index < len; index += sizeof(unsigned int) ) {
uint_chars f;
std::memcpy( f.arr, &p[index], sizeof(unsigned int));
unsigned int result = bit_cast<unsigned int>(f);
result += foo( result );
}
return result ;
}
É lamentável precisarmos desse tipo intermediário, mas essa é a restrição atual do bit_cast .
Capturando violações estritas de aliasing
Não temos muitas ferramentas boas para capturar aliasing estrito em C ++, as ferramentas que possuímos capturam alguns casos de violações estritas de aliasing e alguns casos de cargas e armazenamentos desalinhados.
O gcc usando o sinalizador -fstrict-aliasing e -Wstrict-aliasing pode capturar alguns casos, embora não sem falsos positivos / negativos. Por exemplo, os seguintes casos gerarão um aviso no gcc ( veja ao vivo ):
int a = 1;
short j;
float f = 1.f; // Originally not initialized but tis-kernel caught
// it was being accessed w/ an indeterminate value below
printf("%i\n", j = *(reinterpret_cast<short*>(&a)));
printf("%i\n", j = *(reinterpret_cast<int*>(&f)));
embora não capte este caso adicional ( veja ao vivo ):
int *p;
p=&a;
printf("%i\n", j = *(reinterpret_cast<short*>(p)));
Embora o clang permita esses sinalizadores, aparentemente não implementa os avisos.
Outra ferramenta que temos à nossa disposição é o ASan, que pode capturar cargas e lojas desalinhadas. Embora essas não sejam violações estritamente diretas de alias, elas são um resultado comum de violações estritas de alias. Por exemplo, os seguintes casos gerarão erros de tempo de execução quando criados com clang usando -fsanitize = address
int *x = new int[2]; // 8 bytes: [0,7].
int *u = (int*)((char*)x + 6); // regardless of alignment of x this will not be an aligned address
*u = 1; // Access to range [6-9]
printf( "%d\n", *u ); // Access to range [6-9]
A última ferramenta que vou recomendar é específica para C ++ e não é estritamente uma ferramenta, mas uma prática de codificação, não permite transmissões no estilo C. Tanto o gcc quanto o clang produzirão um diagnóstico para os elencos no estilo C usando o elenco -Wold-style . Isso forçará qualquer trocadilho de tipo indefinido a usar reinterpret_cast; em geral, reinterpret_cast deve ser um sinalizador para uma revisão mais detalhada do código. Também é mais fácil pesquisar em sua base de códigos por reinterpret_cast para realizar uma auditoria.
Para C, já temos todas as ferramentas abordadas e também temos o tis-intérprete, um analisador estático que analisa exaustivamente um programa para um grande subconjunto da linguagem C. Dadas as versões C do exemplo anterior, em que o uso de -fstrict-aliasing perde um caso ( veja ao vivo )
int a = 1;
short j;
float f = 1.0 ;
printf("%i\n", j = *((short*)&a));
printf("%i\n", j = *((int*)&f));
int *p;
p=&a;
printf("%i\n", j = *((short*)p));
tis-interpeter é capaz de capturar todos os três, o exemplo a seguir chama tis-kernal como tis-intérprete (a saída é editada por questões de brevidade):
./bin/tis-kernel -sa example1.c
...
example1.c:9:[sa] warning: The pointer (short *)(& a) has type short *. It violates strict aliasing
rules by accessing a cell with effective type int.
...
example1.c:10:[sa] warning: The pointer (int *)(& f) has type int *. It violates strict aliasing rules by
accessing a cell with effective type float.
Callstack: main
...
example1.c:15:[sa] warning: The pointer (short *)p has type short *. It violates strict aliasing rules by
accessing a cell with effective type int.
Finalmente, há o TySan, que está atualmente em desenvolvimento. Este desinfetante adiciona informações de verificação de tipo em um segmento de memória de sombra e verifica os acessos para ver se eles violam as regras de alias. A ferramenta deve ser capaz de detectar todas as violações de aliasing, mas pode ter uma grande sobrecarga de tempo de execução.
cec++faq.