а ведь действительно, 
mov eax,0x80000000 / neg eax 
возвращает 0x80000000

так а чего вы хотели? 
-21474836478(это 0x8000) умножить на -1 получаем 21474836478 , а это опять же 0x8000, прочитываем правильно и получаем опять  -21474836478 

Это сообщение отредактировал(а) Fazil6 - 22.1.2009, 14:22

блин, точно. Прикольно   

Изменение знака - это не только изменение старшего разряда. В двоично дополнительном коде изменение знака производится так: (~x)+1, т.е.

Интересно... 

Для избежания граблей, так будет правильнее


Это сообщение отредактировал(а) GSasha - 22.1.2009, 17:28

с чего бы это?

Функция не возвратит 1 в случае передачи INT_MIN 

GSasha, такое условие не может быть нигде применено, так что исправлять его не надо 

GSasha, а если sizeof (int) == sizeof (__int64)   

vinter, 100% чего то увлекся увлекательной задачкой, что отошел от реальности   

  

Вот оно  
При передаче INT_MIN происходит знаковый overflow, т.к. (32bit)


А вот тут начинаются подвохи  
Во-первых, если при компиляции включить проверку на overflow, этот код может вызвать ошибку исполнения.
В gcc:



Потом вот что пишет стандарт на счет overflow (C++, C лень искать было):


Т.е. если бы это был unsigned integer, то overflow должен работать как положено, а с signed integer - это UB, архитектурно- и компиляторозависимо.
Насколько я знаю, на маках с powerpc процессором, эта функция всегда возвращает 0 (если у кого есть, попробуйте плиз).

   и еще разок   

Видел что это было использовано для проверки на overflow в сорцах питона (видел в багтрекере gcc баг по этому поводу, были проблемы как раз с powerpc, в итоге пофиксили питон).

Добавлено через 4 минуты и 20 секунд
сцылка