ну делать memcpy алисом для memmove тоже не совсем правильно - найдутся программы которые на это заточились. правильно оставить поведение старой имплементации со всеми ее багами и фичами.
а так вообще удивляют ответы оппонентов. либо совсем оторванные от реальности, либо повышений отхватили за оптимизацию memcpy и теперь не могут вернуть все назад :)
вот ещё одна точка зрения :-) я все-таки думаю, что людей, которые специально расчитывали на одно определенное неправильное поведение функции меньше, чем тех кто случайно пропустил один некорректный случай, в котором memcpy работала как положено :-)
в каком-то смысле то, что предлагает линус - это микрософт-вей: поддерживать совместимость несмотря ни на что, и меня это удивило потому что бывают ситуации где он занимает совсем гиковскую точку зрения. С другой стороны не может не радовать :-)
не, то что они сейчас сделали это вообще бардак. предложение Линуса чинит 90% проблем. но я-таки думаю, что есть программы которые заточились, поэтому самым правильным здесь оставить поведение старой функции (ну либо вернуть ее код обратно).
А я скорее на стороне разработчиков glibc. Если программный продукт заточен на поведение функции, которое не оговорено в стандарте (спецификации) или если при разработке этого программного продукта неоправданно ресурсоёмко точно следовать стандартам, то следует ссылаться на определённую версию библиотеки, а не просто на библиотеку без указания версии. А если разработчик ссылается на библиотеку без указания версии, то он де-факто соглашается с тем, что единственный не спекулятивный аргумент в решении подобных споров есть стандарт (спецификация). Так что изменения не противоречащие стандарту (спецификации) остаются на усмотрение разработчика. А держать различные версии библиотек задача ОС. Например, в Windows в winsxs хранятся свои версии библиотек для каждой программы.
ну видишь, какое дело. Если стандарт говорит, что поведение функции undefined, то это не значит что разработчикам следует выбирать наиболее потенциально разрушительное поведение :-) к тому же проблема там проявлялась только на платформе x64, где поведение функции отличается от x86.
в общем, я согласен с авторами glibc что разработчики adobe криворукие бараны. но я знаю, что большинство разработчиков такие, и специально раскладывать для них грабли в стандартной библиотеке - это детскость какая-то, и тут линус прав, что раз вы можете сделать всем лучше и забесплатно (ну ведь один if-else поставить - это реально бесплатно), почему бы и не сделать.
В общем, вопрос скорее не технический, а политический - стоит glibc прогибаться или нет :-)
На счёт граблей: основные грабли - это скорее наличие в стандарте двух функций копирования памяти. Так что я согласен с цитатой из Кернигана и Пайка, что, по идеи, должна быть только одна функция. На счёт бесплатности: я не в курсе какую оптимизацию делали разработчики glibc (может ты знаешь?), но лишний if-else это лишняя возможность разрушить вычислительный конвейер. И не факт, что Branch Prediction Unit для этого случая будет легко справляться с этим ветвлением. Так что может они и не только из политических соображений рогом упёрлись, хотя кто из знает :)
ну мне-то конечно первому рассказали, что они там накрутили, ага, причем лично позвонили и сказали: "Сергей, мы тут memcpy заоптимизировали, ничего?" :-) Из здравого смысла, если просто изменить либу так, чтобы вместо memcpy всегда вызывался memmove (а это, я так понимаю, можно сделать), то никто пострадать не должен. Ну и я думаю, если бы реально были технические проблемы, то о них бы упомянули. Можно конечно предположить, что эти упоминания не дошли до нас в результате плохого пересказа и так далее
( ... )
Comments 14
а так вообще удивляют ответы оппонентов. либо совсем оторванные от реальности, либо повышений отхватили за оптимизацию memcpy и теперь не могут вернуть все назад :)
Reply
в каком-то смысле то, что предлагает линус - это микрософт-вей: поддерживать совместимость несмотря ни на что, и меня это удивило потому что бывают ситуации где он занимает совсем гиковскую точку зрения. С другой стороны не может не радовать :-)
Reply
Reply
Reply
Reply
(The comment has been removed)
Reply
А если разработчик ссылается на библиотеку без указания версии, то он де-факто соглашается с тем, что единственный не спекулятивный аргумент в решении подобных споров есть стандарт (спецификация). Так что изменения не противоречащие стандарту (спецификации) остаются на усмотрение разработчика.
А держать различные версии библиотек задача ОС. Например, в Windows в winsxs хранятся свои версии библиотек для каждой программы.
Reply
в общем, я согласен с авторами glibc что разработчики adobe криворукие бараны. но я знаю, что большинство разработчиков такие, и специально раскладывать для них грабли в стандартной библиотеке - это детскость какая-то, и тут линус прав, что раз вы можете сделать всем лучше и забесплатно (ну ведь один if-else поставить - это реально бесплатно), почему бы и не сделать.
В общем, вопрос скорее не технический, а политический - стоит glibc прогибаться или нет :-)
Reply
На счёт бесплатности: я не в курсе какую оптимизацию делали разработчики glibc (может ты знаешь?), но лишний if-else это лишняя возможность разрушить вычислительный конвейер. И не факт, что Branch Prediction Unit для этого случая будет легко справляться с этим ветвлением. Так что может они и не только из политических соображений рогом упёрлись, хотя кто из знает :)
Reply
Reply
Reply
Reply
Leave a comment