Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Задет был не только адобский плагин, видел и другие жалобы... 31.03.11 20:48 Число просмотров: 2428
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 31.03.11 20:50 Количество правок: 2
|
Задет был не только адобский плагин, видел и другие жалобы. На мой взгляд разработчики glibc повели себя отвратительно.
Да, в glibc не стандартизировано направление работы memcpy - не описано в документации, это факт, но менять сложившуюся более чем за два десятилетия норму без оповещения публики - дерзко.
Опричники, блин, учащие правильно читать документацию.
|
|
<site updates>
|
Религиозный спор вокруг memcpy и glibc 31.03.11 14:51
Publisher: dl <Dmitry Leonov>
|
Религиозный спор вокруг memcpy и glibc
Red Hat Bugzilla, via avva lj https://bugzilla.redhat.com/show_bug.cgi?id=638477, http://avva.livejournal.com/2323823.html
Любопытная и поучительная история разворачивается вокруг одного обновления glibc, добравшись в последние дни и до рунетовских площадок.
Предыстория восходит к далеким K&R временам, когда в стандартной библиотеке появились функции memcpy и memmove, отличающиеся поведением при обработке перекрывающихся регионов. В зависимости от расположения областей перекрытия можно обеспечить корректную работу, запустив копирование от начала либо от конца. Согласно стандарту, memmove такие проверки делает, memcpy - нет (во имя борьбы за производительность), и ее поведение в таких ситуациях не определено, хотя исторически сложилось так, что все реализации memcpy используют копирование "от начала".
Собственно же история началась в конце прошлого года, когда очередное обновление Fedora сломало 64-битный Adobe Flash. Через некоторое время выяснилось, что причина поломки...
Полный текст
|
|
Являясь пользователем, системным и прикладным программистом,... 31.03.11 23:18
Автор: redbrick Статус: Незарегистрированный пользователь
|
Являясь пользователем, системным и прикладным программистом, сочувствую системщикам. Очень печально, когда твои попытки сделать мир лучше встречаются в штыки. Предлагаю считать крайними прикладных программистов, но вернуть код всё же придётся, либо мириться с тем, что пользователи уходят на другой дистр.
..bw
|
| |
На какой такой "другой дистр", системный и прикладной... 20.09.11 09:19
Автор: some body Статус: Незарегистрированный пользователь
|
> Являясь пользователем, системным и прикладным
> программистом, сочувствую системщикам. Очень печально,
> когда твои попытки сделать мир лучше встречаются в штыки.
> Предлагаю считать крайними прикладных программистов, но
> вернуть код всё же придётся, либо мириться с тем, что
> пользователи уходят на другой дистр.
>
> ..bw
На какой такой "другой дистр", системный и прикладной программист? :-) Библиотека Си (glibc) - отдельный проект. Важный и которым пользуются все "дистры". Направление копирования функцией memcpy не определено, я полагаю, вполне правильно и обоснованно. И нечего ссылаться на недовольных пользователей. Которым халтурщики подсовывают свою дурацкую халтуру, в частности, в виде разного дурацкого флэша... Причём, насколько я знаю, Adobe распространяет свою реализацию вовсе без исходного кода. Вообще, возникают серьёзные сомнения насколько они вправе использовать glibc в своих закрытых реализациях флэша. Я лично не использую flash (отсюда следует, что ряд сайтов, чья работа основана на flash, "неработоспособны" на моём компьётере). Flash вообще из ряда вредоносного ПО и я рекомендую всем пользователям, особенно пользующимся Линукс, и вовсе его не использовать. Во всяком случае в процессе обычного просмотра веб, когда нет, что называется, "особых причин".
Что касается библиотеки, то вообще подобные казусы называются двоичной несовместимостью (в данном случае между разными версиями glibc). На самом деле, существует множество несовместимых реализаций Си библиотеки. И даже "конечный" (или конченный?) :-) пользователь должен знать о несовместимости и её последствиях. Однако в данном случае и этого фактически нет, поскольку, как правильно отмечено, спорный аспект поведения функции не определён и специально отмечен как неопределённый. Несколько удивляет даже то, что изменение поведения этой функции может сказаться на уже готовых программах, потому что memcpy в общем-то должна бы встраиваться прямо на место вызова и не вызываться из собственно библиотеки. Хотя, конечно, и встраивания может тоже не быть :-) Особенно, если программу создавали разного рода халтурщики, отличающиеся криворукостью. Рекламирующие себя, в качестве очередных "спасителей мира"... :-)
|
| | |
Складывается ощущение, что это один человек — «сам себя спросил, сам себе ответил». Всё так печально, аж жуть :-/ 20.09.11 19:35
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| |
ну-ну. "попытки сделать мир лучше встречаются в штыки". Это из оперы: "Хочешь мир без войны? убей всех." 01.04.11 18:05
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
|
Задет был не только адобский плагин, видел и другие жалобы... 31.03.11 20:48
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 31.03.11 20:50 Количество правок: 2
|
Задет был не только адобский плагин, видел и другие жалобы. На мой взгляд разработчики glibc повели себя отвратительно.
Да, в glibc не стандартизировано направление работы memcpy - не описано в документации, это факт, но менять сложившуюся более чем за два десятилетия норму без оповещения публики - дерзко.
Опричники, блин, учащие правильно читать документацию.
|
| |
Да, это просто самый яркий пример по понятным причинам. 31.03.11 21:00
Автор: dl <Dmitry Leonov>
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
