Примітка
Це уривок з мого "Що таке правило суворого відчуження і чому нас хвилює?" докладно описувати.
Що таке суворий псевдонім?
У псевдонімі C і C ++ пов'язане з типом виразів, яким ми можемо отримувати доступ до збережених значень. І в C, і в C ++ стандарт вказує, які типи виразів дозволені для псевдонімів, які типи. Компілятор і оптимізатор дозволяють припустити, що ми суворо дотримуємось правил псевдонімування, звідси і термін суворе правило псевдоніму . Якщо ми намагаємося отримати доступ до значення за допомогою типу не дозволеного, це класифікується як невизначена поведінка ( UB ). Після того, як ми не визначимо поведінку, всі ставки будуть вимкнені, результати нашої програми вже не є надійними.
На жаль, із суворими порушеннями дозволу ми часто отримуємо очікувані результати, залишаючи можливість майбутній варіант компілятора з новою оптимізацією зламати код, який ми вважали дійсним. Це небажано, і важливою є мета зрозуміти суворі правила дозволу та як уникнути їх порушення.
Щоб дізнатися більше про те, чому нас хвилює, ми обговоримо проблеми, які виникають при порушенні суворих правил згладжування, введіть покарання, оскільки загальні методи, що застосовуються при типовому покаранні, часто порушують суворі правила псевдоніму та як правильно вводити каламбур.
Попередні приклади
Давайте розглянемо кілька прикладів, тоді ми можемо поговорити про те, що саме кажуть стандарт (и), вивчимо декілька подальших прикладів, а потім подивимось, як уникнути суворого псевдоніму та виявити порушення, які ми пропустили. Ось приклад, який не повинен дивуватись ( живий приклад ):
int x = 10;
int *ip = &x;
std::cout << *ip << "\n";
*ip = 12;
std::cout << x << "\n";
У нас є int *, що вказує на пам'ять, яку займає int, і це дійсний псевдонім. Оптимізатор повинен припустити, що призначення через ip можуть оновити значення, яке займає x .
Наступний приклад показує згладжування, яке призводить до невизначеної поведінки ( живий приклад ):
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?
}
У функції foo ми беремо int * і float * , у цьому прикладі ми викликаємо foo і встановлюємо обидва параметри, щоб вказувати на те саме місце пам'яті, яке в цьому прикладі містить int . Зауважте, reinterpret_cast вказує компілятору трактувати вираз так, як ніби він має тип, визначений параметром шаблону. У цьому випадку ми кажемо йому, що він має відношення до виразу & x так, як якщо б він мав тип float * . Ми можемо наївно очікувати, що результат другої кути буде 0, але з увімкненою оптимізацією за допомогою -O2 і gcc, і кланг дають такий результат:
0
1
Що може бути не очікуваним, але цілком справедливо, оскільки ми посилалися на невизначену поведінку. Поплавок не може законним чином псевдонім з Int об'єкта. Тому оптимізатор може припустити, що константа 1, що зберігається при перенаправлення i, буде значенням повернення, оскільки зберігання через f не могло би вплинути на об'єкт int . Підключення коду до Провідника компілятора показує, що це саме те, що відбувається ( живий приклад ):
foo(float*, int*): # @foo(float*, int*)
mov dword ptr [rsi], 1
mov dword ptr [rdi], 0
mov eax, 1
ret
Оптимізатор, що використовує типовий аналіз псевдонімів (TBAA), передбачає, що 1 буде повернуто і безпосередньо переміщує постійне значення в регістр eax, який несе повернене значення. TBAA використовує мовні правила щодо того, які типи дозволені для псевдоніму, щоб оптимізувати навантаження та магазини. У цьому випадку TBAA знає, що поплавок не може псевдонімувати і int, і оптимізує подальше навантаження i .
Тепер до Правила
Що саме в стандарті йдеться про те, що нам дозволено і не дозволяють робити це? Стандартна мова не є простою, тому для кожного елемента я спробую навести приклади коду, що демонструє значення.
Що говорить стандарт C11?
Стандарт C11 в розділі 6.5, параграф 7, виражає наступне :
Об'єкт має збережене значення, доступ до якого має лише вираз lvalue, який має один із таких типів: 88)
- тип, сумісний з ефективним типом об'єкта,
int x = 1;
int *p = &x;
printf("%d\n", *p); // *p gives us an lvalue expression of type int which is compatible with int
- кваліфікована версія типу, сумісна з ефективним типом об'єкта,
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
- тип, який є типовим або неподписаним типом, що відповідає ефективному типу об'єкта,
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 має розширення, а також дозволяє призначати неподписаний int * до int *, хоча вони не сумісні типи.
- тип, який є типовим або непідписаним типом, що відповідає кваліфікованій версії ефективного типу об'єкта,
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
- сукупний або союзний тип, який включає один із вищезгаданих типів серед своїх членів (включаючи, рекурсивно, член субагрегату або об'єднання, що міститься), або
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 );
- тип символів.
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.
Що говориться у проекті стандарту C ++ 17
Проект стандарту C ++ 17 у параграфі 11 розділу [basic.lval] говорить:
Якщо програма намагається отримати доступ до збереженого значення об'єкта через glvalue іншого, ніж одного з наступних типів, поведінка не визначена: 63
(11.1) - динамічний тип об'єкта,
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) - версія для динамічного типу об'єкта, кваліфікована cv,
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) - тип, подібний (визначений у 7.5) динамічному типу об'єкта,
(11.4) - тип, який є підписаним або непідписаним типом, що відповідає динамічному типу об'єкта,
// 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) - тип, який є типовим або непідписаним типом, що відповідає версії cv-кваліфікації динамічного типу об'єкта,
signed int foo( const signed int &si1, int &si2); // Hard to show this one assumes aliasing
(11.6) - сукупний або об'єднаний тип, який включає один із вищезазначених типів серед його елементів або нестатичних членів даних (включаючи, рекурсивно, елемент або нестатичний член даних субагрегата або міститься в об'єднанні),
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) - тип, який є типовим базовим класом динамічного типу об'єкта (можливо, що відповідає кваліфікації cv),
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) - тип char, непідписаний char або 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
}
Варто зазначити, що підписані знаки не включені до списку вище, це помітна відмінність від C, яка говорить про тип символу .
Що таке тип набивання
Ми дійшли до цього моменту і нам може бути цікаво, чому ми хотіли б псевдонім? Відповідь, як правило, вводить каламбур , часто використовувані методи порушують суворі правила дозволу.
Іноді ми хочемо обійти систему типів і інтерпретувати об'єкт як інший тип. Це називається типом покарання , щоб повторно інтерпретувати сегмент пам'яті як інший тип. Введення покарань корисно для завдань, які хочуть отримати доступ до базового зображення об’єкта для перегляду, транспортування чи маніпулювання. Типові області, за якими ми вважаємо, що застосовується тип покарання, - це компілятори, серіалізація, мережевий код тощо ...
Традиційно це досягається шляхом взяття адреси об’єкта, накидання його на покажчик типу, який ми хочемо переосмислити як, а потім отримати доступ до значення, або іншими словами шляхом псевдоніму. Наприклад:
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 ) ;
Як ми бачили раніше, це неправдивий псевдонім, тому ми посилаємось на невизначену поведінку. Але традиційно компілятори не скористалися суворими правилами дозволу, і цей тип коду, як правило, працював, розробники, на жаль, звикли робити такі дії. Поширений альтернативний метод для покарання типів - це об'єднання, що є дійсним в C, але невизначена поведінка в C ++ ( див. Прямий приклад ):
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
Це не є дійсним для C ++, і деякі вважають, що мета профспілок полягає лише у впровадженні варіантів типів, і вважають, що використання об'єднань для покарання типу є зловживанням.
Як правильно вводити Pun?
Стандартний метод для типового покарання як для C, так і для C ++ - це memcpy . Це може здатися дещо важким, але оптимізатор повинен розпізнати використання memcpy для набору типів та оптимізувати його та створити регістр для реєстрації переміщення. Наприклад, якщо ми знаємо, що int64_t має той самий розмір, що і подвійний :
static_assert( sizeof( double ) == sizeof( int64_t ) ); // C++17 does not require a message
ми можемо використовувати memcpy :
void func1( double d ) {
std::int64_t n;
std::memcpy(&n, &d, sizeof d);
//...
При достатньому рівні оптимізації будь-який гідний сучасний компілятор генерує ідентичний код попередньо згаданому методу reinterpret_cast або об'єднанню для типового нанесення . Розглядаючи згенерований код, ми бачимо, що він використовує просто зареєструвати mov ( живий приклад компілятора Explorer ).
C ++ 20 та біт_каст
У C ++ 20 ми можемо отримати bit_cast ( реалізація доступна за посиланням із пропозиції ), що дає простий та безпечний спосіб набрати шрифт, а також бути корисним у контексті constexpr.
Нижче наводиться приклад того, як використовувати bit_cast для введення пункту неподписаного int для плавання , ( див. Це в прямому ефірі ):
std::cout << bit_cast<float>(0x447a0000) << "\n" ; //assuming sizeof(float) == sizeof(unsigned int)
У випадку, коли типи « До» та « Від» не мають однакового розміру, це вимагає від нас використання проміжної структури15. Ми будемо використовувати на структуру , яка містить SizeOf (беззнаковое ціле) масив символів ( передбачає 4 байта без знака Int ) , щоб бути від типу і без знака Int , що і щоб ввести.:
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 ;
}
Прикро, що нам потрібен цей проміжний тип, але це обмеження в потоці bit_cast .
Викриття суворих порушень
У нас не так багато хороших інструментів для лову суворого псевдоніму в C ++, інструменти, які ми маємо, виявлять деякі випадки суворих порушень збитку та деякі випадки нерівних навантажень і магазинів.
gcc, використовуючи прапор -fstrict-aliasing та -Wstrict-aliasing, може зафіксувати деякі випадки, хоча не без помилкових позитивів / негативів. Наприклад, наступні випадки генерують попередження в gcc ( дивіться його в прямому ефірі ):
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)));
хоча цей додатковий випадок не буде ( див. це наживо ):
int *p;
p=&a;
printf("%i\n", j = *(reinterpret_cast<short*>(p)));
Хоча кланг дозволяє ці прапори, він, мабуть, насправді не реалізує попередження.
Ще один доступний нам інструмент - ASan, який може ловити нерівні вантажі та магазини. Незважаючи на те, що вони не є прямими чіткими порушеннями спостереження, вони є загальним результатом суворих порушень. Наприклад, наступні випадки створюватимуть помилки виконання під час побудови з клангом за допомогою -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]
Останній інструмент, який я порекомендую, - це специфічний для C ++ і не суворо інструмент, а практика кодування, не допускати кастингу в стилі C. І gcc, і clang будуть виробляти діагностику для анкет у стилі C, використовуючи -Wold-style-cast . Це змусить будь-які невизначені типи каламбурів використовувати reinterpret_cast, загалом reinterpret_cast повинен бути прапором для більш детального перегляду коду. Так само простіше здійснити пошук у вашій кодовій базі для reinterpret_cast для проведення аудиту.
Для C у нас усі інструменти вже охоплені, а також у нас є tis-interpreter, статичний аналізатор, який вичерпно аналізує програму для великого підмножини мови С. З огляду на версії C попереднього прикладу, коли використання -fstrict-aliasing пропускає один випадок ( див. Його в прямому ефірі )
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-інтерпетер здатний спіймати всіх трьох, наступний приклад запускає tis-kernal як tis-interpreter (вихід редагується для стислості):
./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.
Нарешті, є TySan, який наразі розробляється. Цей дезінфікуючий додає інформацію про перевірку типів у сегменті тіньової пам'яті та перевіряє доступ, щоб перевірити, чи порушують вони правила дозволу. Інструмент потенційно повинен бути в змозі виявити всі спокійні порушення, але може мати великі накладні витрати.
cіc++faq.