Религиозный спор вокруг memcpy и glibc
dl // 31.03.11 14:51
Любопытная и поучительная история разворачивается вокруг одного обновления glibc, добравшись в последние дни и до рунетовских площадок.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2011/03/11.html]
Предыстория восходит к далеким K&R временам, когда в стандартной библиотеке появились функции memcpy и memmove, отличающиеся поведением при обработке перекрывающихся регионов. В зависимости от расположения областей перекрытия можно обеспечить корректную работу, запустив копирование от начала либо от конца. Согласно стандарту, memmove такие проверки делает, memcpy - нет (во имя борьбы за производительность), и ее поведение в таких ситуациях не определено, хотя исторически сложилось так, что все реализации memcpy используют копирование "от начала".
Собственно же история началась в конце прошлого года, когда очередное обновление Fedora сломало 64-битный Adobe Flash. Через некоторое время выяснилось, что причина поломки - выполненная с подачи Intel'овских инженеров оптимизация memcpy в glibc, которая теперь иногда стала выполняться "от конца", обеспечивая на некоторых процессорах выигрыш в скорости в полтора-два раза.
Ну а дальше начался цирк с конями диспут между двумя основными точками зрения на проблему.
Радикальная точка зрения, которой придерживаются авторы glibc, если коротко - "адобы каазлы, а того, кто настолько глуп, что доверился исторически сложившемуся поведению, а не описанному в стандарте, нельзя подпускать к клавиатуре".
Согласно более компромиссной позиции, представленной Линусом Торвальдсом, все-таки нехорошо оставлять крайним пользователя, которому по барабану, что там внутри, но который точно знает, что после обновления системы у него ломается Flash. Хотите бороться за производительность - воткните всю оптимизацию внутрь memmove, а memcpy просто превратите в ее алиас - все равно там теперь полно проверок, которых раньше не было в исходной memcpy, и ради отсутствия которых ее поведение и оказалось неопределенным. Т.е. идея в том, что вполне можно добиться того же роста производительности, не ломая совместимость. Хотя и это не совсем так - за 40 с лишним лет существования С наверняка нашлись программисты, использующие привычное поведение memcpy наизнанку - не для копирования, а для размножения шаблона по буферу. Но их уже совсем не жалко.
Конечно, закладываться на привычное, хоть и формально неопределенное поведение - очень, очень плохо, и в том идеальном мире, в котором, видимо, живут разработчики glibc, такое поведение нужно карать высшей мерой программистско-социальной защиты. Но мы живем в реальном мире, где уже стали хрестоматийными случаи, в которых Microsoft иногда приходится в новых версиях ОС воспроизводить недокументированное поведение и ошибки, используемые в популярном софте.
Просто надо понимать, что ушедшая к пользователям программа/библиотека уже не принадлежит полностью своему автору - мы в ответе за тех, кого приручили, и если у них сложился некий шаблон использования, даже не очень на наш взгляд верный, нужно сжать зубы и найти способ существовать с этим. При этом можно и нужно мягко воздействовать на пользователей, пытаясь склонить их в сторону "здорового образа жизни", но рубить сплеча - будет себе дороже.
P.S. Кстати, есть еще какие-то вопросы по поводу того, почему Линукс никогда не завоюет десктопы?
