пост-перепост

Apr 28, 2011 01:10

надеюсь не баян. про умного линуса торвальдса и глупых разработчиков glibc

ЗЫ: кто не знает, чем memove отличается от memcpy, ничего интересного по ссылке не найдет :-)

программизмы

Leave a comment

Comments 14

zmaks April 28 2011, 10:21:07 UTC
ну делать memcpy алисом для memmove тоже не совсем правильно - найдутся программы которые на это заточились. правильно оставить поведение старой имплементации со всеми ее багами и фичами.

а так вообще удивляют ответы оппонентов. либо совсем оторванные от реальности, либо повышений отхватили за оптимизацию memcpy и теперь не могут вернуть все назад :)

Reply

green_nsk April 28 2011, 16:27:04 UTC
вот ещё одна точка зрения :-) я все-таки думаю, что людей, которые специально расчитывали на одно определенное неправильное поведение функции меньше, чем тех кто случайно пропустил один некорректный случай, в котором memcpy работала как положено :-)

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

Reply

zmaks April 28 2011, 16:33:40 UTC
не, то что они сейчас сделали это вообще бардак. предложение Линуса чинит 90% проблем. но я-таки думаю, что есть программы которые заточились, поэтому самым правильным здесь оставить поведение старой функции (ну либо вернуть ее код обратно).

Reply


dashimka April 28 2011, 10:41:38 UTC
Солнце мое... Они правы: you're such a geek? :)

Reply

green_nsk April 28 2011, 16:27:24 UTC
:-) не знаю не знаю

Reply


(The comment has been removed)

green_nsk April 28 2011, 16:27:35 UTC
будете читать теперь мои опусы!

Reply


baeble April 28 2011, 21:17:59 UTC
А я скорее на стороне разработчиков glibc. Если программный продукт заточен на поведение функции, которое не оговорено в стандарте (спецификации) или если при разработке этого программного продукта неоправданно ресурсоёмко точно следовать стандартам, то следует ссылаться на определённую версию библиотеки, а не просто на библиотеку без указания версии.
А если разработчик ссылается на библиотеку без указания версии, то он де-факто соглашается с тем, что единственный не спекулятивный аргумент в решении подобных споров есть стандарт (спецификация). Так что изменения не противоречащие стандарту (спецификации) остаются на усмотрение разработчика.
А держать различные версии библиотек задача ОС. Например, в Windows в winsxs хранятся свои версии библиотек для каждой программы.

Reply

green_nsk April 28 2011, 22:28:46 UTC
ну видишь, какое дело. Если стандарт говорит, что поведение функции undefined, то это не значит что разработчикам следует выбирать наиболее потенциально разрушительное поведение :-) к тому же проблема там проявлялась только на платформе x64, где поведение функции отличается от x86.

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

В общем, вопрос скорее не технический, а политический - стоит glibc прогибаться или нет :-)

Reply

baeble April 28 2011, 22:55:03 UTC
На счёт граблей: основные грабли - это скорее наличие в стандарте двух функций копирования памяти. Так что я согласен с цитатой из Кернигана и Пайка, что, по идеи, должна быть только одна функция.
На счёт бесплатности: я не в курсе какую оптимизацию делали разработчики glibc (может ты знаешь?), но лишний if-else это лишняя возможность разрушить вычислительный конвейер. И не факт, что Branch Prediction Unit для этого случая будет легко справляться с этим ветвлением. Так что может они и не только из политических соображений рогом упёрлись, хотя кто из знает :)

Reply

green_nsk April 28 2011, 23:24:52 UTC
ну мне-то конечно первому рассказали, что они там накрутили, ага, причем лично позвонили и сказали: "Сергей, мы тут memcpy заоптимизировали, ничего?" :-) Из здравого смысла, если просто изменить либу так, чтобы вместо memcpy всегда вызывался memmove (а это, я так понимаю, можно сделать), то никто пострадать не должен. Ну и я думаю, если бы реально были технические проблемы, то о них бы упомянули. Можно конечно предположить, что эти упоминания не дошли до нас в результате плохого пересказа и так далее ( ... )

Reply


ext_428067 May 4 2011, 03:42:38 UTC
Со сменой работы воспрял духом чтоле?

Reply

green_nsk May 4 2011, 05:11:14 UTC
ну я сам сильного подъема пока не чувствую, но все показывает, что да :-)

Reply


Leave a comment

Up