Вот пример для проверки:
#include <iostream>int main(){ std::cout << "-3/3u*3 = " << int(-3/3u*3) << "\n";}
Посмотреть результат можно тут.
Или попробуйте поиграться с этим примером здесь или здесь.
Вообще-то мне не удалось найти хоть какой-то компилятор С++, который бы выдавал результат отличный от -4. Даже старый GCC-4.1.2, clang-3.0.0 или Borland C 1992 года. Так же заметил, что результат одинаковый и для константы, вычисляемой в момент компиляции и для времени выполнения.
Предлагаю внимательно рассмотреть результат выражения
-3/3u*3.
Если убрать приведение к типу intв примере выше, то
получим 4294967292 или 0xFFFFFFFС(-4).
Получается, что компилятор на самом деле считает результат
беззнаковым и равным 4294967292. До
этого момента я был свято уверен, что если в выражении используется
знаковый тип, то и результат будет знаковым. Логично же это.
Если посмотреть откуда берется -4 вместо -3, посмотрим внимательней на ассемблерный код примера, например здесь.
Пример изменю, чтобы результат вычислялся не в момент компиляции, а в момент выполнения:
int main(){ volatile unsigned B = 3; int A = -3/B*3;}
Для x86-64 clang 12.0.0 видим, что используется
беззнаковое деление, хотя числитель откровенно
отрицательное -3:
mov dword ptr [rbp - 4], 3 // B = 3 mov ecx, dword ptr [rbp - 4] mov eax, 4294967293 xor edx, edx div ecx // беззнаковое деление !! imul eax, eax, 3 // знаковое умножение mov dword ptr [rbp - 8], eax
Для x64 msvc v19.28 тот же подход к делению:
mov DWORD PTR B$[rsp], 3 // B = 3 mov eax, DWORD PTR B$[rsp] mov DWORD PTR tv64[rsp], eax xor edx, edx mov eax, -3 ; fffffffdH mov ecx, DWORD PTR tv64[rsp] div ecx imul eax, eax, 3 mov DWORD PTR A$[rsp], eax
Получается, что для деления беззнакового числа на знаковое
используется БЕЗЗНАКОВАЯ операция деления
процессора div. Кстати, следующая команда процессора,
это правильное знаковое умножение imul. Ну явный баг
компилятора. Банальная логика же подсказывает, что знаковый тип
выиграет в приведении типа результата выражения если оба знаковый и
беззнаковый типы используются в выражении. И для знакового деления
требуется знаковая команда деления процессора idiv,
чтоб получить правильный результат со знаком.
Проблема еще и в том, что число 4294967293 не
делится на 3 без остатка:4294967293 = 1431655764 * 3 +
1и при умножении 1431655764 обратно на 3,
получаем 4294967292 или -4. Так что
прикинуться веником и считать, что 4294967293 это то
же -3, только вид сбоку, для операции деления не прокатит.
Благодаря представлению чисел в двоично-дополнительном виде,
операции сложения или вычитания над знаковыми и без-знаковыми
числами выполняются одной и той же командой процессора
(add для сложения и sub для вычитания).
Процессор складывает (или вычитает) только
знаковое со знаковым или только без-знаковое с без-знаковым. И для
обоих этих операций используется одна команда add (или
sub) и побитово результат будет одинаковый (если бы
кто-то решил сделать раздельные операции сложения для знаковых и
без-знаковых типов). Различие только во флагах процессора. Так что
считать знаковое без-знаковым и складывать их оба как без-знаковых
корректно и результат будет побитово правильным в обоих случаях. Но
для деления и умножения этот подход в корне неправильный. Процессор
внутри использует только без-знаковые числа для деления и умножения
и результат приводит обратно в знаковое с правильным признаком
знака. И для этого процессор использует разные
команды для знакового (idiv) и без-знакового деления
(div) и так же и для умножения (imul и
соответственно mul).
Я когда обнаружил, что используется без-знаковое деление, решил, что это бага компилятора. Протестировал много компиляторов: msvc, gcc, clang. Все показали такой же результат, даже древние трудяги. Но мне довольно быстро подсказали, что это поведение описано и закреплено в самом стандарте.
Действительно, стандарт говорит об этом прямо:
Otherwise, if the unsigned operand's conversion rank is greater or equal to the conversion rank of" "the signed operand, the signed operand is converted to the unsigned operand's type.
Иначе, если ранг преобразования без-знакового операнда больше или равен рангу преобразования знакового операнда, то знаковый операнд приводится к типу без-знакового операнда.
Вот где оказывается собака зарыта: "the signed operand
is converted to the unsigned operand's type"!! Ну почему,
почему, Карл!! Логичнее наоборот: "the unsigned operand is
converted to the signed operand's type", разумеется при
соблюдении ранга преобразования. Ну вот как -3
представить без-знаковым числом?? Наоборот кстати можно.
Интересная получается сегрегация по знаковому признаку!
Заметил, что это правило почему-то работает только для операции деления, а операция умножения вычисляется правильно.
Проверим на ассемблере здесь этот пример:
int main(){ volatile unsigned B = 3; int C = -3*B;}
Вот ассемблерный код:
mov dword ptr [rbp - 4], 3 mov eax, dword ptr [rbp - 4] imul eax, eax, 4294967293 mov dword ptr [rbp - 8], eax
Стандарт ничего не говорит о неприменимости этого правила для операции умножения. И деление и умножение должны быть БЕЗЗНАКОВМИ.
Я подумал, что что-то в стандарте сломалось и надо срочно это исправить. Написал письмо напрямую в поддержку Стандарта со всеми моими выкладками и предложением поправить это странное правило стандарта пока еще не поздно.
Ага! Наивный!
Мне ответил любезный молодой сотрудник из Стандарта и подтвердил, что мои выкладки правильны, логика на моей стороне, но поведение компиляторов полностью согласуется со Стандартом и само правило менять не будут, так как оно такое древнее, что непонятно кто и когда его ввел (сотрудник сказал, что искал автора, но не нашел) и поэтому его, как святую корову, трогать никто не будет, хотя вроде логично было бы исправить. Ну и милостиво разрешил поведать эту историю миру. О чем и пишу.
Хоть это исследование и было больше года назад, я до сих пор под впечатлением от многих вещей в этой истории:
-
Как я не натыкался на это раньше? Не один десяток лет интенсивно кодирую на С и С++ с погружением в ассемблер, но только сейчас споткнулся на неё. Хотя может и натыкался ранее, но не мог поверить что причина именно в этом.
-
Ассемблер я выучил раньше С и поэтому всегда считал С удобной заменой Ассемблера. Но правила работы процессоров неизменны и даже языки высокого уровня им следуют.
Интересно, что это правило всё же не работает и для операций с указателями. С ними нет такого поведения. Видать понимают разработчики компиляторов, что иначе рухнет очень многое. Посмотрите этот пример здесь:
int main(){ const unsigned a[] = {3,4,5,6,7}; unsigned p = (&a[0] - &a[3])/3u*3; // -3 unsigned b = -3/3u*3; // -4}
Хоть я и понимаю, что могу ошибаться в логике работы этого мира,
но задумайтесь, в следующий раз садясь в современный, нашпигованный
вычислительной логикой самолёт (или автомобиль), а не сработает ли
вдруг не оттестированный кусок кода в какой-то редкой нештатной
ситуации, и не выдаст ли он -4 вместо элементарных
-3, и не постигнет ли его участь подобная Boeing
737 MAX?
Учитывая, что сейчас кода на С++ производится гораздо больше, чем его успевают покрывать тестами, надежда, что будет отловлена такая базовая операция, тает ниже плинтуса.
Ошибка в команде просессора FDIV у ИнтелаПомните, в начале 2000-х была выявлена ошибка с вычислением в
команде FDIV у Интела. Там было различие в 5 знаке
после запятой в какой-то операции деления. Какой был шум
тогда!!
Но исправили оперативно и быстро. В компиляторы добавили условный
флаг для обхода этой команды. Интел срочно исправил логику в
кристалле и выпустил новые чипы.
И это всего лишь 5-й знак после запятой! Многие его даже и не
заметили, подумаешь, мелочь какая! А тут -4 вместо
-3 и считаем знаковое без-знаковым и вместо
-3 имеем еще и 4294967292! И тишина в
ответ! И в этой тишине тихо падают Боинги.
Предвижу возражение, что есть рекомендация использовать преимущественно без-знаковый тип. Понимаю, с таким правилом Стандарта по другому никак. Но как -4 в беззнаковое перевести, и чтоб всё остальное работало? И почему на других языках и всех процессорах не надо этими танцами с бубном заниматься, а в С++ надо? И что делать с константными выражениями, вычисляемыми компилятором? Вместо элегантных выражений, в которых мы уверены, надо записывать их с оглядкой, чтоб у компилятора небыло изжоги!
Так же найдутся, кто возразит, что ничего нельзя менять, поздно уже, много кода написано, и если в нём есть костыли, то он рухнет. Новые ошибки, они потом будут, а старые - они святое и уже превратились в знакомые фичи.
Как хорошую подсказку познавательно добавить предупреждение в компилятор когда он применяет это правило из Стандарта:"Signed value is intentionally converted to unsigned value. Sorry for crashing one more airplane. Have a nice flight!" Вот удивимся тогда, как мало мы тестируем и как много нам открытий чудных приносит компилятор друг.
Можно еще исправить Стандарт, ограничив правило только операциями сложения и вычитания. Как компромис. Но это крайне маловероятно в этой Вселенной. Да и Боингов еще много летает.
Представьте студента (С) на экзамене у преподавателя по информатике (П) в ВУЗе.- П: Хорошо, последний вопрос на 5. Можно ли привести знаковое
число к беззнаковому типу?
- С: Хе, можно. НУЖНО! Обязательно НУЖНО! Ставте 5, я пойду.
- П: Как НУЖНО?? О_О. Подумайте. Как можно представить, например,
-4 беззнаковым числом? - С: Чего тут думать! Стандарт С++ сказал,
что НУЖНО, значит НУЖНО и точка. А то что -4 станет беззнаковым
очень большим числом - это уже ни печалька Стандарта, ни моя. - П:
Подумайте еще раз. Вы на экзамене по информатике и вас спрашивают о
базовых вещах, которые общие для всех языков программирования и
процессоров, а не только для С++. - С: Чего вы пристали к мне со
своими языками и процессорами. У меня в билете вопрос про С++, вот
я про С++ и отвечаю. А вы про какой то там Ассемблер, базовые вещи,
языки программирования! Стандарт С++ сказал, компилятор сделал, я
ответил! У вас есть вопросы к Стандарту про базовые вещи, вот ему
их и задавайте, а я ответил правильно! - П: Да уж. Подстава
конкретная.
