Недавно наткнулся на такую задачку, возможно кому-нибудь тоже будет интересно.

Имеется C/C++ код:

Вопрос: Может ли функция foo вернуть не 0, почему и от чего это зависит.

Если кто знает, не пишите сразу решение, пусть другие немного подумают  

Придумал почему может , но это не то  , что тут задумано))))

здесь что-то с нулём связано так как 

Это задача математическая (3й класс), а не на С++   
x = -x => 2x = 0 => x = 0
Эрго, foo всегда будет возвращать 0, если только программа не выполняется на машине, где 0 - булева истина   

Это сообщение отредактировал(а) Kallikanzarid - 22.1.2009, 03:58

Люди, ну там же специально проверка стоит x != 0  

Может, если

потому что INT_MIN = –2,147,483,648, а INT_MAX = +2,147,483,647. Хотя зависит, наверное, от компилятора   

все банально
если x - расшарена между 2мя потоками на запись, то ф-я может вернуть и 1 

ЗЫ. все ж таки мы программисты, а не математики...

Добавлено через 9 минут и 19 секунд
хотя, если без приколов, то в стандарте вроде как не сказано, что INT_MIN не должен равняться INT_MAX...

Это сообщение отредактировал(а) Alek86 - 22.1.2009, 11:59

каким образом? хочешь сказать поток может прервать выполнение другого потока во время проверки?

x передается через регистр или стек потока
race'а нет

а где он равняется?   

че то я не понял, почему INT_MIN == -INT_MIN?

MAKCim, про гонки точно, протупил
вопрос не в том, где такое выполняется, а в том, запрещено ли это стандартом

а вообще лично у меня все "нормальные" аргументы в пользу положительного ответа закончились.
если INT_MIN == INT_MAX  - неверно, то я выбираю ответ "нет, по стандарту C++ функция не может вернуть не 0" 

Добавлено через 2 минуты и 21 секунду

да, может, причем это не стандартизировано, то есть когда ОС захочет, тогда и прервет
но тут оно не прокатит :(

Alek86, 

дело не в этом INT_MIN игнорит минус, оставаясь также в значении INT_MIN

задачка про баги С++ %)

Это не баги а фичи, и не С++ а представления чисел в двоичном дополнительном коде   

xvr, а в чем прикол? знак же дожен изменится, - должен сбросить старший разряд

а ведь действительно, 
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 секунд
сцылка

там исходник на С. в С++ вероятно проще, быстрей и понятней проверить так: