[ничего не поделаешь, это...] доставляющая история про memcpy

Скорее всего участки памяти пересекаются. Никто не говорил, что memcpy будет корректно работать в этом случае.

А зачем оно нужно вообще? Какие есть доводы против того, чтобы сделать memcpy алиасом memmove?

Это понятно, тут соль в другом: Торвальдс кричит что нужно фиксить глибц (вернуть все в зад например), а остальные кричат что адобе--говно, и пусть осилят memmove

в скайпе кстате такая же проблема была. И решалась теми же костылями с LD_PRELOAD. Причем проблема сразу из нескольких источников: memcpy они поправили, но на некоторых системах Скайп всё так же перестает передавать звук вообще или уходит в бас (звук становится растянутым и басовым).

> Никто не говорил, что memcpy будет корректно работать в этом случае.

Так проблема в том, что оно и не должно, а оно ж вотано как, работает корректно. Адобифлэш, например, специально пересекающиеся участи копирует, чтобы шифрование своё вселенское эффективнее реализовывать. Теперь оно не работает, юзеры в восторге.

memcpy быстрее

Забавно, что в этой дискуссии вообще не присутствует разработчиков Adobe, только Intel vs Торвальдс лично.

Создается ощущение, что в Адобе этот тред вообще не читали ;) Тестеры глянули что «64-битный флеш не работает», объявили его «кривым» и успокоились.

Пусть меняют на memmove. Это проблемы адоба.

На лоре уже было. И да, Дреппер няшка.

Бида, бида. Чего ж теперь будет то?

memcpy быстрее

Этого так никто и не смог продемонстрировать, сходи по ссылке.

> memcpy быстрее

Покажи тесты.

С утра во френдленте, днем на хабре, вечером в толксах.

Торвальдс - няшка, единственный здравомыслящий участник дискуссии.

> Пусть меняют на memmove. Это проблемы адоба.

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

они могут написать свой memcpy, который всегда будет копировать слева направо. И даже задефайнить его ;) В чем проблема-то?

>Standards are paper. I use paper to wipe my butt every day. That's how much that paper is worth.
Доставило.

Опять?
Stop reopening!

> memcpy быстрее
Это раньше он был прост как валенок и поэтому существенно быстрее, а сейчас и в memcpy понапхали всяких проверок, профит в скорости потерялся.

memmove им тоже не подходят

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

THE USER DOESN'T CARE

Таки Линус шарит :)

Т.е. вот это:
[code]А в новой, при копировании от конца к началу, выходит ошибка. Но не всегда, а лишь на некоторых процессорах и в некоторых условиях.[/code]
нормальное поведение функции?

Линус довольно часто «отличается умом и сообразительностью» в вопросах, где надо забить на фанатичность и думать о пользователях.

Какое счастье все-таки, что Линус не фанатичный задрот, у которого на всё ответ «ССЗБ. УМВРЧЯДНТ?», а нормальный вменяемый человек.

Во всех обсуждениях, которые я наблюдал с участием Линуса он всегда очень адекватен. Я бы сказал самый адекватный

Проблемы не только у адоба. Флеш - первое, в чем обнаружился сабж. Тот же squashfs, например, тоже пострадал.

Может, им вообще отдельный глибц написать?

Кстати, только мне сабж напомнил историю с Коксом и su?

> нормальное поведение функции?

нет, конечно, эта функция вообще не должна в обратную сторону копировать. Но она копирует, и это проблема.

> Кстати, только мне сабж напомнил историю с Коксом и su?

Вроде в истории с su и Коксом последний хотя бы частично прав. А здесь прав однозначно Тролльвалдс - если никто не может продемонстрировать убедительных тестов в превосходстве memcpy над memmove по скорости, то memcpy действительно нужно сделать алиасом memmove. Стандарту это не противоречит, но задо сэкономит кучу нервов криворуким разрабам и несчастным пользователям.

Ну я про общую идею «пофиксим от нефиг делать столетнюю багу, а юзеры пусть обтекают». В данном случае я на 100% на стороне Торвальдса.

Да, нормальное.

Адобы - суки. Линус - дурак. Ульрих - молодчина. Нефига превращать Unix в Windows.

ЗЫ Где-то я всё это уже читал, причём довольно давно...

Если memmove не медленнее memcpy, кто запрещает адобу поменять все вызовы второго на первый?

эта функция вообще не должна в обратную сторону копировать.

в стандарте написано, что она можт копировать как захочет.

и несмотря на

The ANSI C standard defines two functions: memcpy , which is fast but might overwrite memory if source and destination overlap; and memove, which might be slower but will always be correct. The burden of choosing correctness over speed should not be placed upon the programmer; there should be only one function.

Стандарт определяет две функции: memcpy, которая быстрее, но может переписывать память, если исходный кусок памяти и куда копируется — пересекаются. А memmove может оказаться медленнее, но всегда отрабатывает правильно. Бремя выбора между корректностью и скоростью не должно ложиться на программиста, должна существовать только одна функция.

А теперь пусть Керниган, при всём уважении, повторит это тем, кто занимается asm и embedded.

Стандарт такой, какой он есть. И программисты Федорки не просто как-то там поменяли стандарт, а поменяли в точном соответствии с заветами аффтаров: performance over correctness.

Ерунда. Bug как bug.

Рыба гниет с головы. Если есть стандарты, то нужно их исполнять. Идеалогия исправлять правильно написанные библиотеки в угоду кривым проприетарным программам - ущербна.

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

Вместо того, чтобы устраивать срач, лучше написали бы в Адоб.

>Если memmove не медленнее memcpy, кто запрещает адобу поменять все вызовы второго на первый?

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

Но в действительности неправ он — есть стабильный стандарт, и достаточно соблюдать его.

> Если есть стандарты, то нужно их исполнять. Идеалогия исправлять правильно написанные библиотеки в угоду кривым проприетарным программам - ущербна.

Покажи параграф из спецификации C, которому противоречит решение, предложенное Торвальдсом.

Как написали в ЖЖ-сраче:
If you do that, you can be SURE that you've just defined a feature that people will use more and not less.

Very soon, you are going to end up with an enormous pile of «bug-compatibility» junk in your library. In a few more years, you (or someone coming after you) will discover that they have NO idea which «mis-features» are still important to support and which can be safely removed. That will be the end to any forward progress on your library, since the only «specification» you would have is «just the way it worked yesterday», and people will learn to expect just that «spec» from you.

At best, you can create an emergency «temporary» fix with a very clear «expiration date» and try to actively advocate for users to stop misusing your code. The trick, of course, would be to have guts to actually «expire» your fix.

Я могу показать параграф из обычной человеческой совести, и доказать что этой совести нет ни у Адоба, ни у Торвальдса.

> А теперь пусть Керниган, при всём уважении, повторит это тем, кто занимается asm и embedded.

Я занимался asm и занимаюсь embedded. Линус неправ. Стандарт Си предупреждал, кодеры Адоба не слушали - пусть правят свой код. А пока не поправят, придется пускать флеш с LD_PRELOAD - он для таких вещей и придуман.

Сходи выпей валерьянки, после чего возвращайся с техническими аргументами.

>Покажи параграф из спецификации C, которому противоречит решение, предложенное Торвальдсом.

1)Решение Дреппера тем более ей не противоречит.

2)Если у тебя большой опыт поддержки библиотек с огромным количеством костылей, расскажи о нем.

Итак, у нас две (три, если считать еще вариант до внесения этих изменения) соответствующих спецификации реализации, одна из которых ломает неизвестное количество клиентского кода, а вторая — нет. Что выбираешь?

>Торвальдс - няшка, единственный здравомыслящий участник дискуссии.
Он предлагает костыли, лишь бы у пользователя всё работало :)

ANSI C - достаточный аргумент?

Что ANSI C? Номер параграфа из спецификации языка и библиотеки покажи.

> since the only «specification» you would have is «just the way it worked yesterday»

если это реально либа, то можно иметь набор автотестов, которые воспринимать как спецификацию. А в самх тестах кроме кода написать по существу, что именно они требуют.

ISO регистрацию хочет, лень сейчас регистрироваться.