Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, Mr.Cat, Вы писали:

MC>>Не зная причин, обсуждать принятое решение бессмысленно, но идеологически правильным вариантом мог быть выпуск патча для SimCity и включение его в дистрибутив ОСи.
R>Идеалогически правильный вариант отсрочил бы выпуск ОС на неопределенное время, что вероятно привело бы в неопределенно громадным убыткам.
А вот тут-то и появляется самая главная фишка свободного софтам — им-то можно пожертвовать тактической целью ради стратегической.
Ведь за все эти мильоны патчей для кривых приложений все равно кто-то платит, как и за сами кривые приложения — т.е. глобально экономический эффект от таких "шагов навстречу" отрицательный.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Мишень-сан, Вы писали:

МС>>Хотя, конечно, это можно решить элементарно — сделать и memcpy и memmove с проверкой на пересечение регионов, и в зависимости от этого использовать безопасный или небезопасный метод. Сомневаюсь, что несколько лишних инструкций на проверке overlap сделают погоду.

Pzz>Разница в memcpy и memmove как раз в этих нескольких инструкциях. В memmove они есть, а я memcpy их нет.
не совмем так. в первом приближении разница в направлении копирования. во втором приближении начинаются всякие оптимизации. в третьем приближении memmove не такая часто используемая функция чтобы ее оптимизировать и по документации она как раз и используется главным образом для копирования перекрывающихся регионов. и дополнительные проверки ее только затормозят.

Здравствуйте, rsn81, Вы писали:
R>Идеалогически правильный вариант отсрочил бы выпуск ОС на неопределенное время
Я думаю, у тебя по этому вопросу достоверной информации нет.

Здравствуйте, gandjustas, Вы писали:
G>Нифига не правильным. Если разработчики SimCity (или другой программы) выпустят обновление? Или свой патч, который будет несвоместим?
Это выдуманная проблема. Сперва откатить патч от MS, потом патчиться/обновляться. Игроки нынче и не такое терпят.

G>Как раз патч в ОС, который сделали разработчики windows — лучшее решение. Сейчас база данных совместимости программ Windows содержит тысячи, таких патчей, для того чтобы программы работали.
По-русски это называется "костыли". А потом пользователи срут кирпичами оттого, что них после установки программы все ломается (была тут недавно история про софт от хуявея).

G>А вот разработчики glibc положили йух на такую совместимость.
Если у них есть такая возможность — за них можно только порадоваться.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:
G>>Нифига не правильным. Если разработчики SimCity (или другой программы) выпустят обновление? Или свой патч, который будет несвоместим?
MC>Это выдуманная проблема. Сперва откатить патч от MS, потом патчиться/обновляться. Игроки нынче и не такое терпят.
Только для MS создание таких патчей непродуктивно.

G>>Как раз патч в ОС, который сделали разработчики windows — лучшее решение. Сейчас база данных совместимости программ Windows содержит тысячи, таких патчей, для того чтобы программы работали.
MC>По-русски это называется "костыли".
Поддерживать совместимость программ это всегда "костыли".

MC>А потом пользователи срут кирпичами оттого, что них после установки программы все ломается (была тут недавно история про софт от хуявея).
Не понял как это относится к разговору.

G>>А вот разработчики glibc положили йух на такую совместимость.
MC>Если у них есть такая возможность — за них можно только порадоваться.
Да в том то и дело что у них нет, а они думают что есть.

Not a bug.

Please do not reopen!

Здравствуйте, gandjustas, Вы писали:
MC>>Это выдуманная проблема. Сперва откатить патч от MS, потом патчиться/обновляться. Игроки нынче и не такое терпят.
G>Только для MS создание таких патчей непродуктивно.
Это твои домыслы.

MC>>А потом пользователи срут кирпичами оттого, что них после установки программы все ломается (была тут недавно история про софт от хуявея).
G>Не понял как это относится к разговору.
До чего доводят костыли.

G>>>А вот разработчики glibc положили йух на такую совместимость.
MC>>Если у них есть такая возможность — за них можно только порадоваться.
G>Да в том то и дело что у них нет, а они думают что есть.
Она у них есть. Из всех программ сломался только флеш плеер. Ну и хуавей с ним.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, gandjustas, Вы писали:
MC>>>Это выдуманная проблема. Сперва откатить патч от MS, потом патчиться/обновляться. Игроки нынче и не такое терпят.
G>>Только для MS создание таких патчей непродуктивно.
MC>Это твои домыслы.
Ну как бы практика показывает что такие хаки в системе позволяют решать целый класс проблем совместимости. А писать патчи для конкретной программы — дико непродуктивно.


G>>>>А вот разработчики glibc положили йух на такую совместимость.
MC>>>Если у них есть такая возможность — за них можно только порадоваться.
G>>Да в том то и дело что у них нет, а они думают что есть.
MC>Она у них есть. Из всех программ сломался только флеш плеер. Ну и хуавей с ним.
А ниче что это почти 100% пользователей?

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

IT>Разработчики glibc не виноватые, они просто козлы. Всё что надо было сделать, чтобы избежать конфликта — это написать новую версию memcpy — memcpy2 или лучше fastmemcpy, и в своей либе перейти на неё, если им нужно.
И поломать совместимость на уровне сорсов с соответствующим стандарту софтом, который имеет свои личные memcpy2 и fastmemcpy? Нет уж, это путь микрософта, а в адекватном и здравомыслящем мире пусть страдают быдлокодеры и быдлософтоконторы. А в языке программирования С нету функций memcpy2 и fastmemcpy. Есть только memcpy, и работает она так, как написано в документации.

Здравствуйте, Pzz, Вы писали:

Pzz>А представляете, сколько есть недокументированных полезных свойств у разных функций, про которые авторы glibc даже не знают, но которыми кто-нибудь пользуется? Как вы предлагаете девелопить glibc, поддерживая полную совместимость со всеми этими полезными функциями?

Речь не о разных функциях, а о конкретной — memcpy.

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

Мысль не понял, ну да ладно.

IT>>Только не надо демагогии. Ситуация не та. Этой функции 200 лет в обед. Софт который её использует уже давно пережил своих разработчиков. Да и нет никаких десятков версий memcpy. Есть одна, с давно известным, хотя и местами не совсем документированным поведением. Никакие оптимизации не стоят тысяч поломанных из-за них программ. К тому же это не просто поломка из серии вылет с иключением. Это порча памяти! Последствия будут аукаться ещё 200 лет в самые неожиданные моменты.

Pzz>Я, вообще-то, еще когда зеленым сосунком писал свою первую программу на Си, знал, что memcpy можно использовать для неперекрывающихся данных, а для перекрывающихся надо использовать memmove().

Как это оправдывает девелоперов glibc?

Pzz>Вы предлагаете сделать из Си язык для дебилов, неспособных прочитать документацию. Это чудесно, но на чём тогда программировать недебилам, которые знают разницу между этими 2-мя функциями и для которых эта небольшая экономия может быть существенна?

Я предлагаю не ломать тонны кода, больше я ничего не предлагаю.

Здравствуйте, ononim, Вы писали:

IT>>Разработчики glibc не виноватые, они просто козлы. Всё что надо было сделать, чтобы избежать конфликта — это написать новую версию memcpy — memcpy2 или лучше fastmemcpy, и в своей либе перейти на неё, если им нужно.
O>И поломать совместимость на уровне сорсов с соответствующим стандарту софтом, который имеет свои личные memcpy2 и fastmemcpy? Нет уж, это путь микрософта, а в адекватном и здравомыслящем мире пусть страдают быдлокодеры и быдлософтоконторы.

Страдать будут не быдлокодеры, а быдлоюзеры.

O>А в языке программирования С нету функций memcpy2 и fastmemcpy. Есть только memcpy, и работает она так, как написано в документации.

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

Здравствуйте, IT, Вы писали:

O>>А в языке программирования С нету функций memcpy2 и fastmemcpy. Есть только memcpy, и работает она так, как написано в документации.

IT>Если бы оно работало так, как написано в документации, то не позволяло бы себя использовать не по назначению.

Это как?

Здравствуйте, Pzz, Вы писали:

O>>>А в языке программирования С нету функций memcpy2 и fastmemcpy. Есть только memcpy, и работает она так, как написано в документации.

IT>>Если бы оно работало так, как написано в документации, то не позволяло бы себя использовать не по назначению.
Pzz>Это как?

Асёрты, исключения, что там у вас в языке программирования С?

Здравствуйте, Michael7, Вы писали:

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

Если мне не изменяет память, то аналогичные ситуации возникали и с MFC — люди (и я в их числе) использовали "приватные" детали ее реализации при разработке своего софта (хотя в комментариях к этим самым деталям было четко написано про отсутствие гарантий на будущее). МС эти детали периодически меняет и люди переписывают софт. Полностью солидарен с разработчиками glibc и MFC — если уж написано "не влезай — убьет", значит либо не влезай, либо ССЗБ.

P.S.
С самых первых дней программирования на C/C++, прочитав в чем разница между memcpy() и memmove(), всегда использовал последнюю — ведь "если вы параноик, то это не значит, что ОНИ за вами не гонятся..."

Здравствуйте, Michael7, Вы писали:

M>Это привело к неправильному воспроизведению звука в плагине Adobe Flash player и к сбоям в некоторых других менее известных программах.

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


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

Это не проблема разработчиков библиотеки однозначно.

Здравствуйте, gandjustas, Вы писали:

G>Как раз патч в ОС, который сделали разработчики windows — лучшее решение. Сейчас база данных совместимости программ Windows содержит тысячи, таких патчей, для того чтобы программы работали.

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

Здравствуйте, IT, Вы писали:

IT>Разработчики glibc не виноватые, они просто козлы. Всё что надо было сделать, чтобы избежать конфликта — это написать новую версию memcpy — memcpy2 или лучше fastmemcpy, и в своей либе перейти на неё, если им нужно.

Нет, все что им нужно — это проставить новую версию в имени файла и не трогать текущую libc.5.x.x.so. Подозреваю, что они так и сделали. И тогда уже виноваты те, кто линкуется не по жестким ссылкам.

Здравствуйте, IT, Вы писали:

IT>Это порча памяти! Последствия будут аукаться ещё 200 лет в самые неожиданные моменты.

В виндах отродясь эта ф-ия была с порчей памяти в случае перекрытия, никто не жалуется.

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>С самых первых дней программирования на C/C++, прочитав в чем разница между memcpy() и memmove(), всегда использовал последнюю — ведь "если вы параноик, то это не значит, что ОНИ за вами не гонятся..."

Просто memcpy() современные компиляторы инлайнят в пару инструкций процессора, в отличие от memmove(). Так что первая гораздо предпочтительнее в нагрузочных сценариях.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Как раз патч в ОС, который сделали разработчики windows — лучшее решение. Сейчас база данных совместимости программ Windows содержит тысячи, таких патчей, для того чтобы программы работали.

V>Через десят лет их могуть быть уже миллионы, что серьезно скажется на скорости запуска приложений.

Ну скорость запуска не обязана линейно зависеть от количества условий. К тому же от проверок на запуск программ типа симсити под дос можно избавляться со временем.

Повторюсь, тут разница маркетинговая. Разработчики линукса не продают свой продукт, соответственно они могут покласть на неработающие по причине неправильного использования продукты. Microsoft себе позволить такого не может. Если бы у неё половина консамеров былы бы идиотами, которые не знали о различии memmove и memcpy — они были бы вынуждены написать устойчивую к неправильному использованию memcpy.

Причем для этого было бы как минимум 2 причины. Во-первых, если масса пользователей не может нормально (по их мнению) использовать продукт — они не будут покупать его. Это убытки. Во-вторых, саппорт завалили бы бы запросами "почему memcpy глючит при попытке копирования пересекающихся областей". Что тоже убытки, так как тогда потребовалось бы больше ресурсов, либо саппорт был бы перегружен и пострадало качество. Поэтому пропатчить memcpy в таком случае самый экономически эффективный вариант.