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

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

В теории это, безусловно, так, но на практике я проблем с производительностью memmove() не наблюдал даже на девайсах под управлением Windows Mobile 2002. Хотя, безусловно, в каждом конкретном случае нужно делать соответствующие "замеры".

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

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

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

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

а что мешает memmove инлайнить?

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

MC>Не зная причин, обсуждать принятое решение бессмысленно, но идеологически правильным вариантом мог быть выпуск патча для SimCity и включение его в дистрибутив ОСи.

Создание такого патча как минимум противоречит (99%) лицензионному соглашению SimCity, в котором скорее всего оговорен запрет модификации кода.

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

T>Создание такого патча как минимум противоречит (99%) лицензионному соглашению SimCity, в котором скорее всего оговорен запрет модификации кода.

Не грузи их мелочами, они стратегию продумывают. (с)

Правильным было бы по умолчанию использовать быструю версию, но так же включить возможность задания, например, переменной окружения GLIBC_USE_SLOW_MEMCPY, который включает поведение предыдущей версии. Пока есть популярный непропатченный софт, запускать его через врапперы. Через пару лет, когда все пофиксят баги, выбросить эту возможность.

Ну и каким-то образом при компиляции программы без NDEBUG ставить в каждом вызове memcpy assert-ы на проверку перекрытия областей памяти, чтобы помочь новичкам.

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

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

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

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

Такая ситуация как с memcpy приведет к отказу чуть не всех приложений на Виндовсе.

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

Не правильно понимаешь.

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

На C#. На крайняк — на Java.

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

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

I>А не надоо ничего представлять. Девелопить, как девелопили, только проверять свой девелопмент в реальном окружении, как это принято в бизнесе.

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

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

I>Такая ситуация как с memcpy приведет к отказу чуть не всех приложений на Виндовсе.

Что, виндовсные программисты поголовно не слышали о memmove?

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

I>На C#. На крайняк — на Java.

Дык C# вот и создали для дебилов. Непонятно, что им по прежнему надо от Си

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

Pzz>Я думаю, что проверяют. Но ошибки случаются. В "реальном окружении" слишком много программ, да и ошибки такие вылазят при достаточно редких обстоятельствах.

Ошибки вроде этой — вылазят всегда при любых обстоятельствах.

I>>Такая ситуация как с memcpy приведет к отказу чуть не всех приложений на Виндовсе.

Pzz>Что, виндовсные программисты поголовно не слышали о memmove?

Микрософт поддерживает совместимость вплоть до багов если либа общего назначения.

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

Pzz>>Я думаю, что проверяют. Но ошибки случаются. В "реальном окружении" слишком много программ, да и ошибки такие вылазят при достаточно редких обстоятельствах.

I>Ошибки вроде этой — вылазят всегда при любых обстоятельствах.

Почитайте ветку в багрепорте — она (эта ошибка) отнюдь не всегда вылазит.

I>>>Такая ситуация как с memcpy приведет к отказу чуть не всех приложений на Виндовсе.

Pzz>>Что, виндовсные программисты поголовно не слышали о memmove?

I>Микрософт поддерживает совместимость вплоть до багов если либа общего назначения.

Блажен кто верует

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

I>>Микрософт поддерживает совместимость вплоть до багов если либа общего назначения.

Pzz>Блажен кто верует

Вы не правы.

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

J>а что мешает memmove инлайнить?

Ничего, но там уже не пара инструкций.

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

I>>Ошибки вроде этой — вылазят всегда при любых обстоятельствах.

Pzz>Почитайте ветку в багрепорте — она (эта ошибка) отнюдь не всегда вылазит.

Ты сам её прочти.

I>>Микрософт поддерживает совместимость вплоть до багов если либа общего назначения.

Pzz>Блажен кто верует

Тут не надо верить, заглядывай иногда в KB.

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

vsb>Правильным было бы по умолчанию использовать быструю версию, но так же включить возможность задания, например, переменной окружения GLIBC_USE_SLOW_MEMCPY, который включает поведение предыдущей версии. Пока есть популярный непропатченный софт, запускать его через врапперы. Через пару лет, когда все пофиксят баги, выбросить эту возможность.

vsb>Ну и каким-то образом при компиляции программы без NDEBUG ставить в каждом вызове memcpy assert-ы на проверку перекрытия областей памяти, чтобы помочь новичкам.

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

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

IT>>Это порча памяти! Последствия будут аукаться ещё 200 лет в самые неожиданные моменты.
V>В виндах отродясь эта ф-ия была с порчей памяти в случае перекрытия, никто не жалуется.

Потому её никто и не использует для перекрывающихся областей.

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

M>В принципе, ошибка не в glibc, а в прикладных программах и для исправления достаточно банально заменить memcpy(...) на memmove(...) и заново откомпилировать программу.

Это вобщем то классический расклад по линуксу и опенсорсу — один д'Артаньян и все канальи вокруг.

Эдак и про Виндовс можно сказать — ошибки не в Виндовсе а в прикладных программах. Каково ?

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

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

J>>а что мешает memmove инлайнить?

V>Ничего, но там уже не пара инструкций.

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

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

SDB>Если мне не изменяет память, то аналогичные ситуации возникали и с MFC

Изменяет. Код, использующий недокументированные возможности MFC просто не компилировался.

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

IT>Изменяет. Код, использующий недокументированные возможности MFC просто не компилировался.

А, ну да, верно.

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

Pzz>>Почитайте ветку в багрепорте — она (эта ошибка) отнюдь не всегда вылазит.

I>Ты сам её прочти.

Я прочёл и получил массу удовольствия

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

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

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

В данном вопросе я всеми руками за разработчиков либы.