Nota
Questo è tratto dal mio "Cos'è la regola di aliasing rigorosa e perché ci preoccupiamo?" Scrivilo.
Che cos'è l'aliasing rigoroso?
In C e C ++ l'aliasing ha a che fare con quali tipi di espressioni siamo autorizzati ad accedere ai valori memorizzati. In C e C ++ lo standard specifica quali tipi di espressioni sono autorizzati ad alias quali tipi. Il compilatore e l'ottimizzatore possono assumere che seguiamo rigorosamente le regole di aliasing, da cui il termine regola di aliasing rigoroso . Se tentiamo di accedere a un valore utilizzando un tipo non consentito, viene classificato come comportamento indefinito ( UB ). Una volta che abbiamo un comportamento indefinito, tutte le scommesse sono disattivate, i risultati del nostro programma non sono più affidabili.
Sfortunatamente con violazioni rigorose dell'aliasing, otterremo spesso i risultati che ci aspettiamo, lasciando la possibilità che una versione futura di un compilatore con una nuova ottimizzazione rompa il codice che ritenevamo valido. Questo è indesiderabile ed è un obiettivo utile comprendere le rigide regole di aliasing e come evitare di violarle.
Per capire di più sul perché ci preoccupiamo, discuteremo dei problemi che sorgono quando si violano le rigide regole di aliasing, la punzonatura di tipo poiché le tecniche comuni utilizzate nella punzonatura di tipo spesso violano le rigide regole di aliasing e come digitare correttamente il gioco di parole.
Esempi preliminari
Diamo un'occhiata ad alcuni esempi, quindi possiamo parlare esattamente di ciò che dicono gli standard, esaminare alcuni ulteriori esempi e quindi vedere come evitare aliasing rigorosi e rilevare le violazioni che abbiamo perso. Ecco un esempio che non dovrebbe sorprendere ( esempio dal vivo ):
int x = 10;
int *ip = &x;
std::cout << *ip << "\n";
*ip = 12;
std::cout << x << "\n";
Abbiamo un int * che punta alla memoria occupata da un int e questo è un alias valido. L'ottimizzatore deve presumere che le assegnazioni tramite ip potrebbero aggiornare il valore occupato da x .
L'esempio seguente mostra l'aliasing che porta a comportamenti indefiniti ( esempio live ):
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?
}
Nella funzione foo prendiamo un int * e un float * , in questo esempio chiamiamo foo e impostiamo entrambi i parametri in modo che puntino alla stessa posizione di memoria che in questo esempio contiene un int . Nota, reinterpret_cast sta dicendo al compilatore di trattare l'espressione come se avesse il tipo specificato dal suo parametro template. In questo caso gli stiamo dicendo di trattare l'espressione & x come se avesse tipo float * . Possiamo aspettarci ingenuamente che il risultato del secondo cout sia 0 ma con l'ottimizzazione abilitata usando -O2 sia gcc che clang producono il seguente risultato:
0
1
Il che non può essere previsto, ma è perfettamente valido poiché abbiamo invocato un comportamento indefinito. Un float non può validamente alias un oggetto int . Pertanto, l'ottimizzatore può assumere la costante 1 memorizzata durante la dereferenziazione i sarà il valore restituito poiché un archivio tramite f non può influire validamente su un oggetto int . Collegando il codice in Compiler Explorer si vede che è esattamente ciò che sta accadendo ( esempio live ):
foo(float*, int*): # @foo(float*, int*)
mov dword ptr [rsi], 1
mov dword ptr [rdi], 0
mov eax, 1
ret
L'ottimizzatore utilizzando Type-Based Analysis alias (TBAA) assume 1 verrà restituito e sposta direttamente il valore costante nel registro eax che porta il valore restituito. TBAA utilizza le regole delle lingue su quali tipi sono autorizzati all'alias per ottimizzare carichi e negozi. In questo caso TBAA sa che un float non può alias e int e ottimizza il carico di i .
Ora, al Rule-Book
Cosa dice esattamente lo standard che siamo autorizzati e non autorizzati a fare? Il linguaggio standard non è semplice, quindi per ogni articolo cercherò di fornire esempi di codice che dimostrino il significato.
Cosa dice lo standard C11?
Lo standard C11 dice quanto segue nella sezione 6.5 Espressioni paragrafo 7 :
Un oggetto deve avere il suo valore memorizzato accessibile solo da un'espressione lvalue che ha uno dei seguenti tipi: 88)
- un tipo compatibile con il tipo effettivo dell'oggetto,
int x = 1;
int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type int which is compatible with int
- una versione qualificata di un tipo compatibile con il tipo effettivo dell'oggetto,
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
- un tipo di tipo con o senza segno corrispondente al tipo effettivo dell'oggetto,
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 ha un'estensione ed inoltre che permette di assegnare unsigned int * a int * anche se non sono tipi compatibili.
- un tipo di tipo con o senza segno corrispondente a una versione qualificata del tipo effettivo dell'oggetto,
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
- un tipo aggregato o sindacale che includa uno dei tipi summenzionati tra i suoi membri (incluso, ricorsivamente, un membro di un'unione sottaggregata o contenuta), o
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 );
- un tipo di carattere.
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.
Cosa dice lo standard di bozza C ++ 17
La bozza di standard C ++ 17 nella sezione [basic.lval] paragrafo 11 dice:
Se un programma tenta di accedere al valore memorizzato di un oggetto attraverso un valore diverso da uno dei seguenti tipi, il comportamento non è definito: 63
(11.1) - il tipo dinamico dell'oggetto,
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) - una versione qualificata cv del tipo dinamico dell'oggetto,
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) - un tipo simile (come definito in 7.5) al tipo dinamico dell'oggetto,
(11.4) - un tipo di tipo con o senza segno corrispondente al tipo dinamico dell'oggetto,
// 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) - un tipo di tipo con o senza segno corrispondente a una versione qualificata cv del tipo dinamico dell'oggetto,
signed int foo( const signed int &si1, int &si2); // Hard to show this one assumes aliasing
(11.6) - un tipo di aggregato o unione che include uno dei tipi di cui sopra tra i suoi elementi o membri di dati non statici (incluso, ricorsivamente, un elemento o un membro di dati non statici di un'unione sottaggregata o contenuta),
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) - un tipo che è un tipo di classe base (possibilmente qualificato in cv) del tipo dinamico dell'oggetto,
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) - un carattere char, unsigned char o 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 la pena notare che il carattere firmato non è incluso nell'elenco sopra, questa è una notevole differenza da C che indica un tipo di carattere .
Che cos'è il tipo Punning
Siamo arrivati a questo punto e potremmo chiederci, perché dovremmo voler alias? La risposta è in genere digitare pun , spesso i metodi utilizzati violano le rigide regole di aliasing.
A volte vogliamo eludere il sistema dei tipi e interpretare un oggetto come un tipo diverso. Questo si chiama punzonatura , per reinterpretare un segmento di memoria come un altro tipo. La punzonatura del tipo è utile per le attività che desiderano visualizzare, trasportare o manipolare la rappresentazione sottostante di un oggetto. Le aree tipiche che troviamo come tipo di punzonatura utilizzate sono compilatori, serializzazione, codice di rete, ecc ...
Tradizionalmente questo è stato ottenuto prendendo l'indirizzo dell'oggetto, lanciandolo su un puntatore del tipo che vogliamo reinterpretare come e quindi accedendo al valore, o in altre parole con l'aliasing. Per esempio:
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 ) ;
Come abbiamo visto in precedenza, questo non è un alias valido, quindi stiamo invocando un comportamento indefinito. Ma tradizionalmente i compilatori non sfruttano le rigide regole di aliasing e questo tipo di codice di solito ha appena funzionato, purtroppo gli sviluppatori si sono abituati a fare le cose in questo modo. Un metodo alternativo comune per la punzonatura di tipo è tramite i sindacati, che è valido in C ma comportamento indefinito in C ++ ( vedi esempio dal 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
Ciò non è valido in C ++ e alcuni considerano lo scopo dei sindacati esclusivamente per l'implementazione di tipi di varianti e ritengono che l'uso dei sindacati per la punzonatura dei tipi sia un abuso.
Come si digita correttamente Pun?
Il metodo standard per la punzonatura di tipo in C e C ++ è memcpy . Questo può sembrare un po 'pesante ma l'ottimizzatore dovrebbe riconoscere l'uso di memcpy per la punzonatura del tipo e ottimizzarlo e generare un registro per registrare lo spostamento. Ad esempio, se sappiamo che int64_t ha le stesse dimensioni di double :
static_assert( sizeof( double ) == sizeof( int64_t ) ); // C++17 does not require a message
possiamo usare memcpy :
void func1( double d ) {
std::int64_t n;
std::memcpy(&n, &d, sizeof d);
//...
A un livello di ottimizzazione sufficiente, qualsiasi compilatore moderno decente genera un codice identico al metodo reinterpret_cast menzionato in precedenza o al metodo union per la punzonatura dei tipi . Esaminando il codice generato, vediamo che utilizza solo il registro mov ( esempio di Explorer compilatore live ).
C ++ 20 e bit_cast
In C ++ 20 potremmo ottenere bit_cast ( implementazione disponibile nel link dalla proposta ) che offre un modo semplice e sicuro per digitare-pun ed essere utilizzabile in un contesto constexpr.
Il seguente è un esempio di come usare bit_cast per digitare pun un int senza segno su float , ( vederlo dal vivo ):
std::cout << bit_cast<float>(0x447a0000) << "\n" ; //assuming sizeof(float) == sizeof(unsigned int)
Nel caso in cui i tipi To e From non abbiano le stesse dimensioni, è necessario utilizzare una struttura intermedia15. Useremo uno struct contenente un array di caratteri sizeof (unsigned int) ( presuppone che 4 byte unsigned int ) sia il tipo From e un unsigned int come il tipo A .:
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 ;
}
È un peccato che abbiamo bisogno di questo tipo intermedio, ma questo è l'attuale vincolo di bit_cast .
Catturare violazioni rigorose di alias
Non disponiamo di molti buoni strumenti per rilevare un aliasing rigoroso in C ++, gli strumenti in nostro possesso rileveranno alcuni casi di violazioni rigorose dell'aliasing e alcuni casi di carichi e negozi non allineati.
gcc usando il flag -fstrict-aliasing e -Wstrict-aliasing può catturare alcuni casi anche se non senza falsi positivi / negativi. Ad esempio i seguenti casi genereranno un avviso in gcc ( vederlo dal 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)));
sebbene non rileverà questo caso aggiuntivo ( vederlo dal vivo ):
int *p;
p=&a;
printf("%i\n", j = *(reinterpret_cast<short*>(p)));
Sebbene clang consenta queste bandiere, a quanto pare non implementa effettivamente gli avvisi.
Un altro strumento che abbiamo a disposizione è ASan che può catturare carichi e depositi disallineati. Sebbene non si tratti di violazioni di aliasing direttamente rigide, sono un risultato comune di violazioni di aliasing rigorose. Ad esempio, i seguenti casi genereranno errori di runtime quando generati con 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]
L'ultimo strumento che consiglierò è specifico del C ++ e non strettamente uno strumento ma una pratica di codifica, non consentire cast in stile C. Sia gcc che clang produrranno una diagnostica per i cast in stile C usando -Wold-style-cast . Questo costringerà tutti i giochi di parole di tipo indefinito a usare reinterpret_cast, in generale reinterpret_cast dovrebbe essere un flag per una più stretta revisione del codice. È anche più facile cercare nella base di codici reinterpret_cast per eseguire un controllo.
Per C abbiamo già tutti gli strumenti coperti e abbiamo anche tis-interprete, un analizzatore statico che analizza in modo esauriente un programma per un ampio sottoinsieme del linguaggio C. Dato un verion C dell'esempio precedente in cui l'uso di -fstrict-aliasing manca un caso ( vederlo dal 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 è in grado di catturare tutti e tre, l'esempio seguente invoca tis-kernal come tis-interprete (l'output viene modificato per brevità):
./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.
Infine c'è TySan che è attualmente in fase di sviluppo. Questo disinfettante aggiunge informazioni sul controllo del tipo in un segmento di memoria shadow e controlla gli accessi per vedere se violano le regole di aliasing. Lo strumento potenzialmente dovrebbe essere in grado di rilevare tutte le violazioni dell'aliasing ma potrebbe avere un sovraccarico di runtime elevato.
cec++faq.