Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Sshur, Вы писали:
S>>Не понял. По вашему, надо каждый системный вызов обертывать и параноидально проверять на возможность некорректного использования?
M>Скорее речь идет об отладочной версии glibc, где предусмотреть создание лога предупреждений.
Я понял Донца, что пользователи сами должны делать себе такие версии glibc и прочего. А это ИМХО перебор
Шурыгин Сергей
"Не следует преумножать сущности сверх необходимости" (с) Оккам
Re: Ломать ли совместимость в недокументированной области?
Пофиксили поведение функции только в новых версиях системы , зачем же ее ставить прямо сразу. Пройдет определенное время и пофиксят совместимости . Вот и все. Я чего то не понимаю ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[10]: Ломать ли совместимость в недокументированной област
Здравствуйте, DOOM, Вы писали:
DOO>Я замечу, что memcpy на ассемблере — это (без учета инициализации регистров) одна инструкция. DOO>Так что накладные расходы на рантайм проверку совершенно неприемлемы.
К сожалению, уже лет 10 как попытка сделать "memcpy на ассемблере" в одну инструкцию породит больше накладных расходов, чем в несколько. Все приличные компиляторы выполняют развёртку цикла, и она работает быстрее, чем rep movsd.
Крайне не рекомендую учить матчасть в 2010 году по книге "ассемблер 386 для профессионалов".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: Ломать ли совместимость в недокументированной области
Здравствуйте, March_rabbit, Вы писали: V>>Нет, там будет одна инструкция ассемблера по копированию блока памяти. M_>ну да. примерно такой цикл она и будет выполнять, только со счетом от значения ECX до 0. Если со времен 386 процессора не появилось принципиально новых команд в основной линейке. Я со времен универа ассемблером не осень занимаюсь.
Дело не в новых командах, а в новой архитектуре. И во времена твоего универа rep movs* была ничуть не быстрее по тактам, чем ручное написание цикла. А сейчас развёртывание цикла позволяет существенно сэкономить. Современные компиляторы практически никогда не используют префикс rep.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Ломать ли совместимость в недокументированной области?
Здравствуйте, Michael7, Вы писали:
M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков...
Я считаю что в данном случае виноваты разработчики API, в частности реализовавшие memcpy, правильно работающей и с перекрывающимися блоками, т.к. это расходится с документацией, но вызов требует больших затрат времени ЦПУ чем простое копирование, т.к. требует дополнительных проверок. Следовательно, если это свойство широко используется, значит его нужно сохранить. А подобное поведение разработчиков glibc похоже вызвано тем что они чувствуют себя пупом земли. Думаю если это продолжится, или всплывут другие такиеже случаи, то glibc будет иметь альтернативные сборки.
Re[8]: Ломать ли совместимость в недокументированной области
Здравствуйте, Mr.Cat, Вы писали:
G>>>>А вот разработчики glibc положили йух на такую совместимость. MC>>>Если у них есть такая возможность — за них можно только порадоваться. G>>Да в том то и дело что у них нет, а они думают что есть. MC>Она у них есть. Из всех программ сломался только флеш плеер. Ну и хуавей с ним.
И после этого кто-то агитирует за линукс на десктопе в реальной жизни. В следующий раз сломают гуй и скажут, "ну и гуй с ним".
Re[2]: Ломать ли совместимость в недокументированной области
Здравствуйте, shasa, Вы писали:
S>Я считаю что в данном случае виноваты разработчики API, в частности реализовавшие memcpy, правильно работающей и с перекрывающимися блоками, т.к. это расходится с документацией, но вызов требует больших затрат времени ЦПУ чем простое копирование, т.к. требует дополнительных проверок.
Дополнительных проверок как раз не было, они просто тупо mov-или, продвигаясь сверху вниз по адресам. А потом им пришло в голову использовать векторные инструкции процессора для ускорения.
С документацией ничего не расходилось, в ней говорилось только, что правильный результат гарантируется при неперекрывающихся областях памяти.
S> Следовательно, если это свойство широко используется, значит его нужно сохранить.
Вот это и есть камень преткновения: стоит или нет. Как видно, имеются доводы и за и против. С одной стороны, такое поведение де-факто похоже с самых первых версий линукса, с другой стороны — все-таки никто не обещал правильного поведения во всех случаях.
S> А подобное поведение разработчиков glibc похоже вызвано тем что они чувствуют себя пупом земли. Думаю если это продолжится, или всплывут другие такиеже случаи, то glibc будет иметь альтернативные сборки.
А и так уже были или есть.
Re[2]: Ломать ли совместимость в недокументированной области
IT>Разработчики glibc не виноватые, они просто козлы. Всё что надо было сделать, чтобы избежать конфликта — это написать новую версию memcpy — memcpy2 или лучше fastmemcpy, и в своей либе перейти на неё, если им нужно.
Или realmemcpy(), и, по необходимости, добавить absolutely_real_memcpy_read_documentation_before_use().
В крайнем случае понадобится добавить absolutely_real_memcpy_read_documentation_TWICE_before_use() и почти наверняка не будет проблем.