о началах программирования

[avva]

(эта запись будет интересна лишь программистам и сочувствующим)

Из недавно обнаруженного бага в дистрибутиве Линукса Федора сложилась очень поучительная история, которую на мой взгляд неплохо бы преподавать в университетах, на уроках программирования, чтобы объяснять студентам не только как ключевые слова писать, но и как работать вместе с другими

Comments

[stefashka]

Линус просто ведёт себя как взрослый человек и зрелый разработчик. А разработчики Федоры всё ещё не переболели юношеским максимализмом и бодро моськают.

[lazyreader]

Ну надо и их понять. С чего бы им вот прямо подрываться и из-за адобовского тупоумия бежать править код, покрывать его тестами, выпускать релиз libc?

Это всё-таки не то же самое, чтобы студенту пару строчек в скрипте поправить.

[taganay]

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

[lazyreader]

Если точно, то грабли не в коде, а в стандарте; также грабли в тех, кто садится писать на языке, не понимая, что это язык низкого уровня.

[motto]

прямой репортаж из банки с тараканами - ок

[aalien]

…в голове.

[motto]

Злой ты!

[aalien]

не я злой, опенсорс такой!

[sleeping_death]

*double facepalm*

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

[lazyreader]

А что им надо было сделать? Выкинуть интеловскую оптимизацию и вернуть старый код memcpy? Это, кстати, единственное, что удовлетворило бы всех (кроме тех, кто хочет получить оптимизацию).

[avva]

Нет, прочитайте внимательнее. У них есть намного лучше решение (если они верят в интеловскую оптимизацию): переместить ее в memmove(), после проверки регионов, и заалиасить memcpy() в memmove().

В подавляющем большинстве случаев регионы не пересекаются (это вообще редко происходит), а цена дополнительных инструкций для проверки того, что они не пересекаются, совершенно и абсолютно тривиальна по сравнению с тем, что и так делается каждый раз в "оптимизированной" версии.

[lazyreader]

http://avva.livejournal.com/2323823.html?thread=78031215#t78031215

[lazyreader]

Интересная история, и все в ней ведут себя так, как я бы ожидал.

Торвальдс - прагматик. Предпочитает "free as in free beer, not as in free speech" (как-то так, по памяти).

Дреппер - давно известен упёртостью; разработчики glibc правы в принципе, но, наверное, могли бы уступить. В конце концов, стандарт C не требует от memcpy, чтобы она именно не проверяла перекрытия и не вела себя как memmove.

Adobe - просто не могла упустить удобный случай написать глючный софт и, вместо исправления, сохранять гордое молчание. Дреппер прав, по крайней мере, в одном - если софт пишут люди, которых вообще не стоит подпускать к клавиатуре, то результат будет именно таким.

[taganay]

Софт пишут люди, поэтому если в библиотеке имеются грабли, то на эти грабли будет наступленно наиболее болезненным способом. Поэтому если есть возможность грабли убрать, их надо вначале убрать, а уж потом разбираться, кого можно подпускать к клавиатуре, а кого - нет.

[taganay]

Обычное поведение означает, что memcpy байты из источника скопирует в приёмник. Линус это и предлагает - чтобы байты копировались всегда, независимо от того, перекрываются источник с приемником или нет.
Мне трудно представить, что кто-то обкурится настолько сильно, что будет сознательно закладываться на то, что система грохнется, если источник и приемник в memcpy находятся в некотором взаимном расположении.

[igorlord]

Don't know, but it seems that memcpy did not have any bugs. You cannot have implementation bugs, if the implementation fits the spec. It can be a spec bug (and it can easily argued that it is), but no one is/was proposing to change the spec for C.

A different question is what to do about this situation, when many applications have managed to screw up and misuse memcpy?

It is the answer to this question that seems more interesting. I would, indeed, vote for using memmove instead of memcpy by default and add a compiler parameter and, possibly, pragma to turn on the original "fast" memcpy.

I do have some small reservations about this approach, though, because in a typical server-type application, when you run a profiler, memcpy typically shows up in the top 20-30 functions (because it is used so often to copy around little buffers and strings). This "fix" would make it even slightly more expensive.

[alexcohn]

+1 "чума на оба ваши дома"

и "оптимизированный" вариант glibc, и "надежный" Торвальдса оба делают memcpy непригодным для того, что мы используем очень часто - копирования множества маленьких объектов. Оба варианта, как указал чуть ниже lazyreader, ломают широко известный "hack", в котором memcpy используется для размножения короткого фрагмента ("слова") памяти.

Чего я не понимаю во всём этом шуме - где патч работающая версия от Adobe? Можно сколько угодно спорить, нужно ли исправлять glibc, но если все вынуждены пользоваться неофициальной версией флеш-плейера, то что-то не ладно в адобском королевстве.

А пока для Федоры решение должно быть - воспользоваться методами Microsoft Windows, и вписать в систему tweak: для флеш плейера такой-то версии - подставить memmove вместо memcpy. Никто не знает, к каким странным эффектам подобная подстановка может привести в еще одной неприкаянной аппликации.

[avva]

Я не знаю, откуда взялось это "ломают широко известный hack". Ни в одной современной версии memcpy он и так не работает (потому что они копируют минимум по 4 байта, а на 64-битных архитектурах и по 8, кажется).

[alexcohn]

Вот-вот, именно что по 4 байта: с одним байтом работает memset(). Конечно, для 64-битной системы это не сработает, нужно делать оффсет 8 байт. Впрочем, простенький поиск не показывает, чтобы этот трюк часто использовали (или по крайней мере, трубили об этом по свету).

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

Хотя, ковыряясь сегодня в кривых имплементациях Android framework, я хотел бы конечно сказать "система должна строго следовать спецификациям, а не оглядываться на те или иные usecases".