Виявлення переписаного переповнення в C / C ++

На перший погляд, це питання може здатися дублікатом Як виявити переповнення цілих чисел? , проте насправді це суттєво відрізняється.

Я виявив, що виявлення переповнення цілого числа без підпису є досить тривіальним, виявляючи підписане переповнення в C / C ++ насправді складніше, ніж думає більшість людей.

Найбільш очевидним, але наївним способом зробити це буде щось на зразок:

int add(int lhs, int rhs)
{
 int sum = lhs + rhs;
 if ((lhs >= 0 && sum < rhs) || (lhs < 0 && sum > rhs)) {
  /* an overflow has occurred */
  abort();
 }
 return sum; 
}

Проблема цього полягає в тому, що згідно зі стандартом C, переповнене ціле число зі знаком є невизначеною поведінкою. Іншими словами, згідно зі стандартом, як тільки ви навіть спричиняєте переповнення із підписом, ваша програма стає такою ж недійсною, як якщо б ви визначили нульовий покажчик. Отже, ви не можете спричинити невизначену поведінку, а потім спробувати виявити переповнення по факту, як у наведеному вище прикладі перевірки стану.

Незважаючи на те, що наведена вище перевірка, ймовірно, буде працювати на багатьох компіляторах, ви не можете на неї розраховувати. Насправді, оскільки стандарт C говорить, що переповнення цілочисельного підпису невизначене, деякі компілятори (наприклад, GCC) оптимізують подану вище перевірку коли встановлені прапори оптимізації, оскільки компілятор вважає, що переповнений підпис неможливий. Це повністю розриває спробу перевірити переповнення.

Отже, ще одним можливим способом перевірки переповнення буде:

int add(int lhs, int rhs)
{
 if (lhs >= 0 && rhs >= 0) {
  if (INT_MAX - lhs <= rhs) {
   /* overflow has occurred */
   abort();
  }
 }
 else if (lhs < 0 && rhs < 0) {
  if (lhs <= INT_MIN - rhs) {
   /* overflow has occurred */
   abort();
  }
 }

 return lhs + rhs;
}

Це видається більш перспективним, оскільки насправді ми не додаємо два цілих числа разом, поки заздалегідь не переконаємось, що виконання такого додавання не призведе до переповнення. Таким чином, ми не спричиняємо невизначеної поведінки.

Однак це рішення, на жаль, набагато менш ефективне, ніж початкове рішення, оскільки вам доведеться виконати операцію віднімання, лише щоб перевірити, чи буде ваша операція додавання працювати. І навіть якщо вас не хвилює цей (невеликий) показник ефективності, я все ще не впевнений, що це рішення є адекватним. Вираз lhs <= INT_MIN - rhsздається точно таким, як вираз, який компілятор може оптимізувати, вважаючи, що переповнений підпис неможливий.

То чи є тут краще рішення? Щось, що гарантовано 1) не спричинить невизначеної поведінки, і 2) не надасть компілятору можливості оптимізувати перевірки від переповнення? Я думав, що, можливо, є якийсь спосіб зробити це, перекинувши обидва операнди на непідписані та виконуючи перевірки, прокатуючи власну арифметику доповнення двох, але я не дуже впевнений, як це зробити.

Ваш підхід із відніманням правильний і чітко визначений. Компілятор не може оптимізувати його.

Іншим правильним підходом, якщо у вас є більший цілочисельний тип, є виконання арифметики для більшого типу, а потім перевірка, чи підходить результат у менший тип при перетворенні його назад

int sum(int a, int b)
{
    long long c;
    assert(LLONG_MAX>INT_MAX);
    c = (long long)a + b;
    if (c < INT_MIN || c > INT_MAX) abort();
    return c;
}

Хороший компілятор повинен перетворити все додавання та ifоператор у intвелике додавання та єдине умовне перехідне переповнення і ніколи насправді не виконувати більшого додавання.

Редагувати: Як зазначив Стівен, у мене виникають проблеми з отриманням (не дуже хорошого) компілятора, gcc, для генерації розумного asm. Код, який він генерує, не дуже повільний, але, безумовно, неоптимальний. Якщо хтось знає варіанти цього коду, які змусять gcc робити правильно, я б хотів їх бачити.

Ні, ваш другий код неправильний, але ви близькі: якщо ви встановите

int half = INT_MAX/2;
int half1 = half + 1;

результатом додавання є INT_MAX. ( INT_MAXзавжди непарне число). Отже, це дійсне введення. Але у вашому розпорядку у вас будеINT_MAX - half == half1 і ви перервете. Хибнопозитивний.

Цю помилку можна виправити, поставивши <замість<= обох чеків.

Але тоді ваш код не є оптимальним. Буде зроблено наступне:

int add(int lhs, int rhs)
{
 if (lhs >= 0) {
  if (INT_MAX - lhs < rhs) {
   /* would overflow */
   abort();
  }
 }
 else {
  if (rhs < INT_MIN - lhs) {
   /* would overflow */
   abort();
  }
 }
 return lhs + rhs;
}

Щоб побачити, що це справедливо, вам потрібно символічно додати lhsз обох сторін нерівності, і це дає вам точно арифметичні умови, що ваш результат виходить за межі.

IMHO, найпростіший спосіб боротьби з переповненням чутливого коду С ++ - це використання SafeInt<T>. Це крос-платформний шаблон C ++, розміщений на плекс-коді, який забезпечує гарантії безпеки, які ви тут бажаєте.

• http://safeint.codeplex.com/

Я вважаю, що це дуже інтуїтивно зрозуміле використання, оскільки воно забезпечує безліч тих самих схем використання, що і звичайні числові операції, і виражає потоки та недоліки через винятки.

Що стосується випадку gcc, з приміток до випуску gcc 5.0 ми бачимо, що тепер він містить додаткову __builtin_add_overflowперевірку переповнення:

Додано новий набір вбудованих функцій для арифметики з перевіркою переповнення: __builtin_add_overflow, __builtin_sub_overflow і __builtin_mul_overflow, а також для сумісності з clang також інші варіанти. Ці вбудовані модулі мають два інтегральні аргументи (для яких не потрібно мати однаковий тип), аргументи поширюються на нескінченну точність підписаного типу, +, - або * виконується над ними, а результат зберігається у цілочисельній змінній, вказаній на за останнім аргументом. Якщо збережене значення дорівнює результату нескінченної точності, вбудовані функції повертають false, інакше true. Тип цілочисельної змінної, яка буде містити результат, може відрізнятися від типів перших двох аргументів.

Наприклад:

__builtin_add_overflow( rhs, lhs, &result )

З документа gcc вбудовані функції для виконання арифметики з перевіркою переповнення ми бачимо, що:

[...] ці вбудовані функції мають повністю визначену поведінку для всіх значень аргументів.

clang також надає набір перевірених арифметичних вбудованих елементів :

Clang пропонує набір вбудованих програм, що реалізують перевірену арифметику для програм, що мають важливе значення для безпеки, таким чином, щоб це було швидко та легко виразно в C.

в цьому випадку вбудованим буде:

__builtin_sadd_overflow( rhs, lhs, &result )

Якщо ви використовуєте вбудований асемблер, ви можете перевірити прапор переповнення . Інша можливість полягає в тому, що ви можете використовувати тип даних safeint . Рекомендую прочитати цю статтю про Integer Security .

Найшвидший можливий спосіб - це використання вбудованого GCC:

int add(int lhs, int rhs) {
    int sum;
    if (__builtin_add_overflow(lhs, rhs, &sum))
        abort();
    return sum;
}

На x86 GCC компілює це у:

    mov %edi, %eax
    add %esi, %eax
    jo call_abort 
    ret
call_abort:
    call abort

який використовує вбудований в процесор виявлення переповнення.

Якщо ви не в порядку з використанням вбудованих GCC, наступним найшвидшим способом є використання бітових операцій над бітами знаків. Підписане переповнення додатково відбувається, коли:

• два операнди мають однаковий знак, і
• результат має інший знак, ніж операнди.

Знаковий біт ~(lhs ^ rhs)знаходиться на iff, якщо операнди мають той самий знак, а знаковий біт lhs ^ sum- на iff, якщо результат має інший знак, ніж операнди. Отже, ви можете зробити додавання у беззнаковій формі, щоб уникнути невизначеної поведінки, а потім використовувати знаковий біт ~(lhs ^ rhs) & (lhs ^ sum):

int add(int lhs, int rhs) {
    unsigned sum = (unsigned) lhs + (unsigned) rhs;
    if ((~(lhs ^ rhs) & (lhs ^ sum)) & 0x80000000)
        abort();
    return (int) sum;
}

Це компілюється у:

    lea (%rsi,%rdi), %eax
    xor %edi, %esi
    not %esi
    xor %eax, %edi
    test %edi, %esi
    js call_abort
    ret
call_abort:
    call abort

що набагато швидше, ніж передача на 64-розрядний тип на 32-розрядному комп'ютері (з gcc):

    push %ebx
    mov 12(%esp), %ecx
    mov 8(%esp), %eax
    mov %ecx, %ebx
    sar $31, %ebx
    clt
    add %ecx, %eax
    adc %ebx, %edx
    mov %eax, %ecx
    add $-2147483648, %ecx
    mov %edx, %ebx
    adc $0, %ebx
    cmp $0, %ebx
    ja call_abort
    pop %ebx
    ret
call_abort:
    call abort

Можливо, вам пощастить перетворити на 64-розрядні цілі числа та протестувати подібні умови. Наприклад:

#include <stdint.h>

...

int64_t sum = (int64_t)lhs + (int64_t)rhs;
if (sum < INT_MIN || sum > INT_MAX) {
    // Overflow occurred!
}
else {
    return sum;
}

Можливо, ви захочете ближче розглянути, як тут працюватиме розширення вивісок, але я думаю, що це правильно.

Як щодо:

int sum(int n1, int n2)
{
  int result;
  if (n1 >= 0)
  {
    result = (n1 - INT_MAX)+n2; /* Can't overflow */
    if (result > 0) return INT_MAX; else return (result + INT_MAX);
  }
  else
  {
    result = (n1 - INT_MIN)+n2; /* Can't overflow */
    if (0 > result) return INT_MIN; else return (result + INT_MIN);
  }
}

Я думаю, що це має працювати на будь-які законні INT_MINта INT_MAX(симетричні чи ні); функція, як показано на кліпах, але повинно бути очевидно, як отримати інші способи поведінки).

Очевидним рішенням є перетворення на unsigned, щоб отримати чітко визначену поведінку без знаку переповнення:

int add(int lhs, int rhs) 
{ 
   int sum = (unsigned)lhs + (unsigned)rhs; 
   if ((lhs >= 0 && sum < rhs) || (lhs < 0 && sum > rhs)) { 
      /* an overflow has occurred */ 
      abort(); 
   } 
   return sum;  
} 

Це замінює невизначену поведінку підписаного переповнення перетворенням визначених реалізацією значень поза діапазоном між підписаними та беззнаковими, тому вам потрібно перевірити документацію компілятора, щоб точно знати, що відбудеться, але це має бути принаймні чітко визначеним, і слід правильно робити на будь-якій машині з двома комплементами, яка не піднімає сигнали про перетворення, як це майже кожна машина та компілятор C, побудовані за останні 20 років.

У разі додавання двох longзначень, переносний код може розділити longзначення на низьку та високу intчастини (або на shortчастини, якщо справа longмає такий самий розмір, як int):

static_assert(sizeof(long) == 2*sizeof(int), "");
long a, b;
int ai[2] = {int(a), int(a >> (8*sizeof(int)))};
int bi[2] = {int(b), int(b >> (8*sizeof(int))});
... use the 'long' type to add the elements of 'ai' and 'bi'

Використання вбудованої збірки - це найшвидший спосіб націлення на певний процесор:

long a, b;
bool overflow;
#ifdef __amd64__
    asm (
        "addq %2, %0; seto %1"
        : "+r" (a), "=ro" (overflow)
        : "ro" (b)
    );
#else
    #error "unsupported CPU"
#endif
if(overflow) ...
// The result is stored in variable 'a'

Я думаю, що це працює:

int add(int lhs, int rhs) {
   volatile int sum = lhs + rhs;
   if (lhs != (sum - rhs) ) {
       /* overflow */
       //errno = ERANGE;
       abort();
   }
   return sum;
}

Використання volatile утримує компілятор від оптимізації тесту, оскільки він вважає, що sumце могло змінитися між додаванням та відніманням.

Використовуючи gcc 4.4.3 для x86_64, збірка для цього коду робить додавання, віднімання та тест, хоча вона зберігає все в стеку та непотрібні операції зі стеком. Я навіть намагався, register volatile int sum =але збірка була однаковою.

Для версії з лише int sum =(без мінливості або реєстру) функція не виконала перевірку і зробила додавання, використовуючи лише одну leaінструкцію (lea це Ефективна адреса завантаження і часто використовується для додавання, не торкаючись реєстру прапорів).

Ваша версія є більшим кодом і має набагато більше стрибків, але я не знаю, що було б краще .

Для мене найпростіша перевірка - перевірка ознак операндів та результатів.

Давайте вивчимо суму: переповнення може відбуватися в обох напрямках, + або -, лише тоді, коли обидва операнди мають однаковий знак. І, очевидно, переповнення буде, коли знак результату не буде таким, як знак операндів.

Отже, такої перевірки буде достатньо:

int a, b, sum;
sum = a + b;
if  (((a ^ ~b) & (a ^ sum)) & 0x80000000)
    detect_oveflow();

Редагувати: як запропонував Нільс, це правильна ifумова:

((((unsigned int)a ^ ~(unsigned int)b) & ((unsigned int)a ^ (unsigned int)sum)) & 0x80000000)

І відколи інструкція

add eax, ebx 

призводить до невизначеної поведінки? У порівнянні наборів інструкцій Intel x86 такого немає.