тролль - это не только ценный жир, но и 3-4 легкоусвояемых коммента ежедневно
Как известно, не-x86-ое железо - это миф, придуманный эпплом, чтобы продавать больше маков. )))
Но вдруг у вас сейчас под рукой имеется это самое мифическое не-x86-ое железо с Си-компилятором на нём?
Тогда посчитайте, пожалуйста, что получится, если "скастовать" NaN к целому типу?
#include <stdio.h>
int main()
{
double x = 0.0/0.0; // NaN
printf("%lx\n",(long)x);
return 0;
}
На x86-железе конвертация происходит через x87 FPU (в полном соответствии с Intel-овской спецификацией) и получается MIN_INTEGER (пишет на экране 8000000000000000)
А что происходит на другом железе? Какие значения там могут получиться?
Обратите внимание, что если выражение (long)NaN будет вычисляться в момент компиляции, то ответ может быть численно другой (напр., gcc в таких случаях ставит 0)!
Интересует значение, которое получается именно в рантайме на разном железе.
Возможно, придётся поставить volatile или как-то по-другому отключить оптимизацию.
Также стоит на всякий случай обратить внимание, что (long)NaN это совсем не то же самое что *(long*)(&NaN) - получаются разные численные результаты.
В первом случае действует некоторая нетривиальная логика, не фиксированная стандартом языка Си,
а во втором случае получаем вполне ожидаемое битовое представление плавучки согласно IEEE 754.
Что у вас есть под рукой? Мак, роутер, андроид? Попробуйте.
Но вдруг у вас сейчас под рукой имеется это самое мифическое не-x86-ое железо с Си-компилятором на нём?
Тогда посчитайте, пожалуйста, что получится, если "скастовать" NaN к целому типу?
#include <stdio.h>
int main()
{
double x = 0.0/0.0; // NaN
printf("%lx\n",(long)x);
return 0;
}
На x86-железе конвертация происходит через x87 FPU (в полном соответствии с Intel-овской спецификацией) и получается MIN_INTEGER (пишет на экране 8000000000000000)
А что происходит на другом железе? Какие значения там могут получиться?
Обратите внимание, что если выражение (long)NaN будет вычисляться в момент компиляции, то ответ может быть численно другой (напр., gcc в таких случаях ставит 0)!
Интересует значение, которое получается именно в рантайме на разном железе.
Возможно, придётся поставить volatile или как-то по-другому отключить оптимизацию.
Также стоит на всякий случай обратить внимание, что (long)NaN это совсем не то же самое что *(long*)(&NaN) - получаются разные численные результаты.
В первом случае действует некоторая нетривиальная логика, не фиксированная стандартом языка Си,
а во втором случае получаем вполне ожидаемое битовое представление плавучки согласно IEEE 754.
Что у вас есть под рукой? Мак, роутер, андроид? Попробуйте.
-
-
10.06.2015 в 08:48-
-
10.06.2015 в 12:11unspecified behavior
this.
В IEEE 754 написано только, что нужно выставить эксепшен Invalid Operation (да, именно на конверсию, а не на деление), а такая деталь как результат некорректной операции уже будет описана в доках на архитектуру или ABI.
Что до результатов, на арм-ах чаще всего 0.
Проверил на рабочем девайсе с набором инструкций ARMv6TEJ и софтовой плавающей точкой, так оно в общем-то и есть.
Компилятор - гцц от CodeSourcery c GNU EABI.
-
-
10.06.2015 в 12:47