Pull to refresh

Comments 33

Видя такие топики на хабре я очень жалею, что не могу отдать недельное количество голосов за карму автору топика.
Чё-то жёсткий сегодня денёк на O2 приколы :) Сам недавно 6 часов в SIGSEGV убил ради того чтобы узнать "-O2 implies -fstrict-aliasing", челябинский алиасинг я минимум от -O3 ожидал. Еще и вылезло на жёстком reorder через инлайны (варнинга не было), включая reorder вокруг отладочных printf'ов, что хрен поймёшь когда конкретно оно падает :) пришлось лепить __asm__ __volatile__ ("" ::: «memory»); барьеры вокруг отладочного вывода.
Могу рассказать о своём опыте. Нашел 3-4 неприятных бага в WPF. Сначала запостил на форумы MSDN (англоязычные, само собой). Там посоветовали отправить баги в Microsoft Connect. Отправил. Так они там 2 уже года и висят, со статусом Active.
это печально, учитывая то, что WPF является одной из ключевых технологий MS…
Вы проверьте или бампните баги — они вообще правят но не всегда ставят статусы…
Продуктовые команды знают о багах на connect.microsoft.com, есть приоритеты, видимо, что ваши баги пока не такие приоритетные, в плане не так много случаев затрагивают. Вообще, продуктовые команды очень хорошо прислушиваются к запросам кастомеров.
Я положительно отношусь к MS, но тем не менее не очень верится про приоритеты. Взять тот же баг с windows phone, который затрагивает кучу пользователей (достаточно погуглить, все форумы, касающиеся wp7 усеяны сообщением о баге), связанный с зависанием телефона в режиме плеера после обновления Mango. Первые рапорты в MS пошли как только Mango стало доступно для разработчиков, до сих пор не починили, а времени прошло с того момента очень прилично.
Причем судя по форумам — это один из очень немногих багов, и самый досаждающий, что не дает усомниться в его приоритетности.
То что я нашел — в общем-то не критические баги:
— Самое противное — игнорирование языковых настроек. Всегда используется системная локаль по умолчанию (форматы времени, разделители чисел и т.д.). Вытекающие проблемы, думаю легко понять.
— Свойства UIElement IsArrangeValid/IsMeasureValid имеют значение TRUE до первого вызова Arrange/Measure.
— TextBox обрабатывает событие нажатия на return, даже если свойство AcceptsReturn = false.
— DateTimePicker теряет DateTime.Kind если его не указывать явно.
— Некорректно работает свойство UIElement.IsMouseOver если над элементом раположен PopUp — его значение равно — true если курсор находится в области PopUp'а.
— Если тип значения, передаваемого через Binding реализует ICommand, и Binding'у назначен конвертер, то при попытке передачи значения выбрасывается исключение.

Как-то так.
Сначала пытался найти в коде undefined behaviour, но вроде тут всё просто и однозначно. Интересный баг.
P.S. В GCC 4.6.1 linux amd64 не проявляется.
Похоже на implementation-defined правого сдвига. А так-то баг, конечно.
Разработчики компилятора перемудрили с п. 5.8/3 стандарта C++, про implementation-defined правого сдвига знаковых типов.
Поменял в коде знаковый тип int на unsigned int, ошибка осталась.
Что-то я не понял. Почему виноват компилятор, если по Стандарту сдвиг вправо для знаковых типов не определён?

Цитата из Стандарта: «The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.»
Специально для того, чтобы исключить этот недостаток сдвига знаковых — исправил int на unsigned int в двух местах: в параметрах функции f и в определении переменной x.

От этого ассемблерный код тоже поменялся в двух местах, вместо команды sar теперь shr, что и следовало ожидать, в ассемблере это тоже поправил.

Все остальное, влючая ошибку — осталось.
Я ниже написал, что ошибся. В данном примере работа ведётся с битами 0-15, поведение знакового бита при сдвиге никак не могло влиять на результат. Это баг компилятора.
Был неправ. Число 0x76543210 — неотрицательное, на него этот пункт не распространяется.

Баг в компиляторе, да.
Скажите, а почему x объявлен как static?
Изначально это был не просто int x, а целый массив int x[], который с помощью функции f() развертывался в другой массив char a[], более большой по размеру, но с которым в дальнейшем работать удобнее.

А объявлен массив x был static для того, чтобы не было лишнего копирования из сегмента _DATA в _STACK.

Например, вот так объявлять неправильно, будет лишнее копирование при каждом входе в функцию
(в данном случае это функция main) так как x лежит в стеке, а {1,2,3} в данных:
int x[3]={1,2,3};

А вот так правильно, x в данных и {1,2,3} в данных, оба места совпадают, копирования не будет:
static int x[3]={1,2,3};

Но более того, если теперь взять и убрать static — то «ошибка -O2» исчезает.
То есть static — это важный элемент проблемного кода.
Ага, понятно. Не знал, что это был массив, а для одной переменной просто очень странно выглядит.
Если этот массив вкомпиливается намертво, а потом только переводится в более удобный вид, то, может, лучше написать тулзу, которая будет генерить финаьный массив и вкомпиливать его?
При всём моём уважении к Майкрософту, в последнее вемя (начина с года 2005) отстают или не привносят в направление Visual Studio ничего особо нового. Баги правятся долго и муторно создавая при этом новые баги. В техподдержке вообще молодцы — «да, знаем, поправим». А когда это будет сделано, хз. Студия за это время пять раз переродиться успеет.
Ну по поводу «ничего нового» это не правда. Для .net по крайней мере нового предостаточно, еще 2010 WPF'ом обернут.
Ваши слова «Легко увидеть» под ассемблерными вставками очень сильно расстраивают некоторых программистов =)
Которые не могут прочитать пол экрана текста о синтаксисе ассемблерной команды в википедии?

Дык какое же это «легко увидеть», если надо лезть в википедию?
Для тех кто уже заранее сходил, легко. У программистов обычно не атрофировано такое качество как любознательность. А если уж совсем атрофировано, лучше будет подыскать другую профессию.
Комментарии «Line 19», «Line 20» несколько сбивают с толку т.к. не соответствуют строкам приведённого ранее исходника.
Сразу обратил внимание на то, что результат работы цикла завистит от последовательности его выполнения выполнения — и действительно, в работающем примере такого нет.
Возможно компилятор, каким-то волшебным образом считает k константой на этапе оптимизации?
точнее, не понимает, что оно меняется
Only those users with full accounts are able to leave comments. Log in, please.