здесь искал http://govnokod.ru/? Не баги, но все же...

Периодически заглядываю. Это действительно тема для лекции, но не для этой   

Еще надо? Из относительно недавнего; из радостей обновления компилятора.
Уже не помню с каких пор пользуюсь следующей хэш-функцией "для разброса" точек (когда точка является ключом хэш-мэпа).

Ну то есть старшую часть дабла при преобразовании в инт сносит, остаток отлично разбрасывается. Т.е. так было раньше, на MSVC 6 и MSVC 2003. Переезжаем на 2008. Сразу никто ничего не заметил, ибо эффект заметен только на большом объеме данных. В общем, вдруг замечаем тормоза, которых раньше вроде бы не было: помещение точек в граф подтормаживает, когда точек много. Долго чешем репу, прежде чем догадываемся заглянуть внутрь хэш-мэпа (ну кому придет в голову ковыряться в стандартных контейнерах, которые всю жизнь работали и чего бы им теперь сломаться). И видим одну корзину... т.е. имеем вместо мэпа массив. Оказывается, умники из MS тихой сапой изменили поведение при переполнении, и теперь там какая-то константа. Долго рылась в MSDN во всяких отличиях компиляторов, но никакого упоминания об изменении этого поведения не нашла. Вот спасибо ребятам! 

Earnest, честно говоря, не очень понял... если не сложно, можешь пояснить кодом ? как было на VC-6 и как стало на MSVC-2008
и каким образом приведённая функция Hash перестала работать...

borisbn, меня, тоже очень заинтересовал этот момент. По случаю под рукой оказалась как VC-6, так и MSVC-2008.
Итак, тестовая программка:

Выход VC-6:


Выход MSVC-2008:


Выход gcc, совпадает с MSVC-2008, пруф

Но, во всех трех случаях, упрекнуть создателей компиляторов абсолютно не в чем! 
поскольку стандарт (как всегда!), нифига не стандартизирует:

Earnest. Интересный баг, спасибо. Не знал про него.

Мои баги не столь интересны, тем более по последствиям. А вот если рассказать несколько исторических баек на эту тему, то кмк будет веселее. Прямо начиная от происхождения слова баг и т.п.
10 худших багов в истории человечества (правда, там моль благородно названа "мотыльком")...
Изучение знаменитых (и не очень знаменитых) ошибок

Это сообщение отредактировал(а) feodorv - 21.6.2012, 06:05

Да, разумеется, это UB в принципе. Т.е. теоретически. Но дело в том, что в незапамятные годы я списала это где-то как пример хорошей хэш-функции для  2-х и более компонентных ключей. Тогда над UB задумываться было не модно. И оно работало как надо. Это такая маленькая часть кода, и так давно работающая, что воспринималась как нечто само собой разумеющееся.
borisbn, volatile привел вполне показательные данные. Только в моем случае в 2008 были сплошные 0х80000000, т.к. координаты немаленькие.
Да, они, конечно, имели право, но хоть бы написали где-нибудь пару слов. Дело в том, что это было не единственное тихое изменение поведения. И много-много радостей по этому поводу. Т.е. набор опций проекта, который нормально работал в 2003, стал по-другому работать в 2008. 
Например, еще поменяли выравнивание секций в образе по умолчанию, и у меня защита развалилась. Да к тому же "забыли" описать опцию, которая это дело помогает починить. 

  
Ненавижу, когда приходишь в привычный супермаркет за молочком-хлебушком, а там опять все переставили. И ходишь как дура между рядами, ищешь свой хлебушек, вместо того чтобы валить по более важным делам. Я понимаю, зачем это делается, хотя на меня действует обратным образом: когда я в злобе, я покупаю меньше. Но зачем разработчики компиляторов непрерывно все "переставляют", для меня загадка. Не иначе как для того, чтобы нам скучно не стало.

Еще вспомнилось, уже из древних времен. Если кто помнит, во времена доса и светлой памяти турбо С готового функционала для работы с мышью не было. Полагалось писать что-то вроде драйвера, вроде называлось это резидентной программой. Поскольку она могла получить управление в любой момент, ей полагалось перед работой сохранить значения регистров, а потом восстановить. Программка простая, пара десятков строк на ассемблере. Тоже из серии "написали и забыли". Ну и вот, после 2-3 лет жизни на 286-х компьютерах наступает светлая эпоха 386-го процессора. ОС и программы остаются 16-разрядными, основная программа на С++, поэтому замены одного ящика на другой я особо не замечаю. И вот в мышином резиденте остается сохранение\восстановление 16-разрядных регистров. При этом,  программа в основном работала нормально (видимо, старшая часть регистров имела значение не часто). Но иногда ее начинало вдруг глючить. Зависело это, похоже, исключительно от расположения звезд: она могла работать целыми днями без эксцессов. Попытка выловить баг отладкой напоминала погоню за горизонтом: только вроде находишь место падения, ставишь туда точку прерывания, а она валится совсем в другом, где раньше работала. Жуть, в общем. Несколько дней я убила на погоню за тенью, пока случайно не вспомнила про мышиный драйвер и не посмотрела, как там регистры сохраняются.

но в некоторых супермаркетах это обычное дело ;)
страшно, если в компиляторах/стандартах все станет также  

И что , мсдос в real mode работает и там 16 разрядные регистры будут хоть на атлоне 64. Так что баг не в смене проца был.

Да, я еще забыла сказать, что после перехода на 386 проц компилятору включили соответствующую опцию (что можно использовать его команды). Речь, конечно, не идет о том, что старая прога, которая работала под 286, перестала работать под 386. Программа, разумеется, перекомпилировалась под 386 и вообще продолжала развиваться. 

Это я уже собрал, хотелось бы чего то не столь распространенного по сети   

volatile, спасибо. Хорошо объяснили. Всё понятно.

Earnest, тоже спасибо за очередное напоминание, что UB не должно быть в программе ни в коем случае. Даже если оно и работает...
А баг с мышкой - жеееесть. Хоть, наверное, за давностью лет и не имеет смысла, но сочувствую   

Это сообщение отредактировал(а) borisbn - 21.6.2012, 13:27

Итак, лекцию прочел. Хотя не успел перевести весь сопроводительный текст, кидаю как есть.
Когда текст доделаю, кину еще раз отдельно


Присоединённый файл ( Кол-во скачиваний: 16 )
 bugs.zip 786,61 Kb

Уже, наверное, не актуально, но на потом - 90гг, трабла между передачей параметров из кода MS в код Borland, при передаче двухбайтных параметров:
все параметры при передаче выравниваются по границе 4 байта, и код от одного производителя считает значимыми младшие два байта, а код второго производителя - что значимые старшие. Меняем размерность передаваемого параметра на int - и все работает. Недавно на такую же штуку кто-то с хабра наткнулся, при попытке компилировать на gcc под ARM