Re[11]: Ломать ли совместимость в недокументированной област - Философия программирования

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

Причем некоторые из разработчиков используют это API не описанным в документации способом или даже прямо там запрещенном (не в юридическом смысле) и никаких проблем от этого до сих пор не возникало, потому что, де-факто, оно работало нужным образом, хотя и не позволенным документацией.

В один прекрасный момент разработчики чего-то там у себя переписали и внезапно недокументированное поведение функции из API изменилось, что поломало совместимость и привело к ошибкам в работе и возмущениям.

И вот кто тут прав?

Ситуация невымышленная. Недавно эта история приключилась в Linux.
Подробности можно узнать из этого обсуждения.

Вкратце произошло вот что.

Есть важнейшая системная библиотека glibc (ее разработчики работают в основном в RedHat), в которой содержится сишный рантайм. В ней есть функция memcpy, копирующая память и описанная в документации как:

MEMCPY(3) Linux Programmer's Manual MEMCPY(3)

NAME
memcpy — copy memory area

SYNOPSIS
#include <string.h>

void *memcpy(void *dest, const void *src, size_t n);

DESCRIPTION
The memcpy() function copies n bytes from memory area src to memory
area dest. The memory areas should not overlap. Use memmove(3) if the
memory areas do overlap.

Она копирует из одной области памяти в другую заданное число байт. Специально указывается, что источник и приемник не должны пересекаться, если пересекаются необходимо использовать вместо memcpy функцию memmove. При том такое описание было с весьма древних пор, минимум с 1993-ого года или вообще с самого начала.

Но де-факто, реализация memcpy в glibc позволяла спокойно копировать и пересекающиеся области памяти. И вот разработчики чего-то там оптимизировали для увеличения скорости копирования, после чего в случае пересекающихся областей памяти копироваться они стали неверно.

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

Разработчики glibc закрыли сообщение об ошибке по причине, что это не ошибка. Дискуссия развернулась довольно серьезная. В ней даже отметился лично Линус Торвальдс, который отнюдь не считает, что в glibc были правы, и даже ехидно спрашивает, собираются ли они выпустить дистрибутив Fedora 14 с заведомо неработоспособным флеш плеером?

В принципе, ошибка не в glibc, а в прикладных программах и для исправления достаточно банально заменить memcpy(...) на memmove(...) и заново откомпилировать программу. Для OpenSource — это особо не проблема, но в Linux-e работают и проприетарные программы, которые производители могут и не спешить исправлять. Правда Линус предложил способ решить проблему путем использования своей реализации memcpy и подкладывании своей библиотеки для конкретной программы. Но это костыль.

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

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

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

Моя имха, что разработчик здесь прав на все 100%. Если что-то они просят не делать, то это, в частности, и для того, чтобы у них в будущем было пространство для маневра.
Схожий пример — зарезервированные поля в протоколах. Их обычно очень много — и, если вдруг кто-то начнет их использовать, чтобы передавать какие-то свои данные, то ни к чему хорошему это не приведет — потому что рано или поздно авторы протокола найдут применение этим полям.

P.S. Указанная проблема решается путем использования предыдущей версии glibc для пострадавших программ — вполне себе способ, учитывая, что проприетарные программы итак в 90% случаев используют библиотеки с префиксом compat

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

M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков.

M>Причем некоторые из разработчиков используют это API не описанным в документации способом или даже прямо там запрещенном (не в юридическом смысле) и никаких проблем от этого до сих пор не возникало, потому что, де-факто, оно работало нужным образом, хотя и не позволенным документацией.

It depends, как говорится. Тут недавно в КУ пролетала история про Microsoft, которая при выпуске я так понимаю 95-й винды затачивала системные библиотеки под конкретные глючившие игрушки и приложения. Со стороны разработчиков, кажется неправильно в системные библиотеки вводить условия, что если пользователь запускает SimCity, то менеджер памяти работает по другому. А со стороны пользователей хорошо, что старые программы работают в новой системе.

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

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

[skipped]

ИМХО, виноваты авторы прикладного ПО. Во всех доках по С API жирными буквами написано не использовать memcpy для пересекающихся регионов. В С/С++ такие штуки караются UB. Если разрабы флеш-плеера не изволють читать доку...
Хотя, конечно, это можно решить элементарно — сделать и memcpy и memmove с проверкой на пересечение регионов, и в зависимости от этого использовать безопасный или небезопасный метод. Сомневаюсь, что несколько лишних инструкций на проверке overlap сделают погоду.

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

M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков.

M>Причем некоторые из разработчиков используют это API не описанным в документации способом или даже прямо там запрещенном (не в юридическом смысле) и никаких проблем от этого до сих пор не возникало, потому что, де-факто, оно работало нужным образом, хотя и не позволенным документацией.

M>В один прекрасный момент разработчики чего-то там у себя переписали и внезапно недокументированное поведение функции из API изменилось, что поломало совместимость и привело к ошибкам в работе и возмущениям.

M>И вот кто тут прав?
Вот, к примеру, сбивают сосульки с крыши. Оградили тротуар и написали, "не ходить".
Много раз люди ходили и ничего. Но вот как-то сосулька прилетела кому-то на голову.
И вот кто тут прав?

avalon 1.0rc3 rev 365, zlib 1.2.3

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

M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков.

M>Причем некоторые из разработчиков используют это API не описанным в документации способом или даже прямо там запрещенном (не в юридическом смысле) и никаких проблем от этого до сих пор не возникало, потому что, де-факто, оно работало нужным образом, хотя и не позволенным документацией.

M>В один прекрасный момент разработчики чего-то там у себя переписали и внезапно недокументированное поведение функции из API изменилось, что поломало совместимость и привело к ошибкам в работе и возмущениям.

M>И вот кто тут прав?

Ответ известен. Если разработчики — это разработчики Linux, значит виноваты те, кто использовал недокументированные возможности, ибо ССЗБ. Если речь идет о Microsoft, то виноват Microsoft, ибо криворукие, не могут обеспечить обратную совместимость.

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

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

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

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

Разница в memcpy и memmove как раз в этих нескольких инструкциях. В memmove они есть, а я memcpy их нет.

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

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

Представляете, каково это программировать под систему, в которой десяток версий memcpy, и такая же ситуация с другими функциями, причем никто не может внятно объяснить, за давностью лет, чем эти функции различаются?

Если бы разработчики glibc действовали по вашему рецепту, так бы оно и было.

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

Pzz>Представляете, каково это программировать под систему, в которой десяток версий memcpy, и такая же ситуация с другими функциями, причем никто не может внятно объяснить, за давностью лет, чем эти функции различаются?

Представляете сколько софта использует эту функцию, а сколько софта использует софт, который использует эту функцию? Почему-то, если что-то в совместимости отваливается у MS, то они козлы, а glibs, сцука, д'Артаньяны, борющиеся против злобных кулхацкеров.

Pzz>Если бы разработчики glibc действовали по вашему рецепту, так бы оно и было.

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

Ладно, забираю слова обратно. Разработчики glibs не козлы. Они — дебилы. Наверняка это изменение сделал какой-нибудь школяр только вчера допущенный к телу.

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

IT>Представляете сколько софта использует эту функцию, а сколько софта использует софт, который использует эту функцию? Почему-то, если что-то в совместимости отваливается у MS, то они козлы, а glibs, сцука, д'Артаньяны, борющиеся против злобных кулхацкеров.

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

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

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

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

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

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

S>It depends, как говорится. Тут недавно в КУ пролетала история про Microsoft, которая при выпуске я так понимаю 95-й винды затачивала системные библиотеки под конкретные глючившие игрушки и приложения. Со стороны разработчиков, кажется неправильно в системные библиотеки вводить условия, что если пользователь запускает SimCity, то менеджер памяти работает по другому. А со стороны пользователей хорошо, что старые программы работают в новой системе.
Это описывал Джоэл Спольски в своей статье Как Microsoft проиграла битву за API.

"Взгляните с точки зрения покупателя. Вы купили программы X, Y и Z. Затем вы обновились до Windows XP. Теперь ваш компьютер внезапно зависает, и программа Z вообще не работает. Вы скажите своим друзьям: «Не обновляйтесь до Windows XP. Она внезапно зависает и не совместима с программой Z». Будете ли вы дебажить вашу систему, чтобы определить, что программа X причина зависаний, а программа Z не работает, потому что использует недокументированные сообщения Windows? Конечно нет. Вы вернете коробку с Windows XP и получите обратно деньги. (Вы купили программы X, Y и Z несколько месяцев назад. 30-дневный срок возврата уже для них не действует. Единственное, что вы можете вернуть, это Windows XP.)"

Я впервые услышал об этом от одного из разработчиков популярной игры SimCity, который поведал мне о критической ошибке в их программе: она использовала память сразу после ее освобождения. Главное табу, нарушение которого прощалось в DOS, но карается в Windows, где освобожденную память тут же стащит другое работающее приложение. Тестеры в команде разработки Windows протестировали множество популярных приложений, чтобы убедиться, что все работает без сбоев, но SymCity зависала. Они сообщили это разработчикам Windows, которые дизассемблировали SymCity, шаг за шагом в дебаггере найдя ошибку, и добавили специальный код, проверяющий наличие SymCity в памяти и запускающий распределитель памяти в специальном режиме, в котором SymCity разрешается использовать память после ее освобождения.

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

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

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

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

Все это прекрасно и очень правильно при одном условии... Пишется новая программа.
Кто может гарантировать что каждую отдельно взятую старую программу писал не лопух?

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

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

H>Все это прекрасно и очень правильно при одном условии... Пишется новая программа.
H>Кто может гарантировать что каждую отдельно взятую старую программу писал не лопух?

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

Здравствуйте, rsn81, Вы писали:
R>добавили специальный код, проверяющий наличие SymCity в памяти и запускающий распределитель памяти в специальном режиме, в котором SymCity разрешается использовать память после ее освобождения.
Не зная причин, обсуждать принятое решение бессмысленно, но идеологически правильным вариантом мог быть выпуск патча для SimCity и включение его в дистрибутив ОСи.

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

H>>Кто может гарантировать что каждую отдельно взятую старую программу писал не лопух?

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

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

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

MC>Здравствуйте, rsn81, Вы писали:
R>>добавили специальный код, проверяющий наличие SymCity в памяти и запускающий распределитель памяти в специальном режиме, в котором SymCity разрешается использовать память после ее освобождения.
MC>Не зная причин, обсуждать принятое решение бессмысленно, но идеологически правильным вариантом мог быть выпуск патча для SimCity и включение его в дистрибутив ОСи.
Нифига не правильным. Если разработчики SimCity (или другой программы) выпустят обновление? Или свой патч, который будет несвоместим?

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

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

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

Здравствуйте, 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(), всегда использовал последнюю — ведь "если вы параноик, то это не значит, что ОНИ за вами не гонятся..."

[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]

Здравствуйте, 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 в таком случае самый экономически эффективный вариант.

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

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

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

[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]

Здравствуйте, 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-ы на проверку перекрытия областей памяти, чтобы помочь новичкам.

Здравствуйте, 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 просто не компилировался.

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

[ posted via RSDN@Home 1.1.4 stable SR1 r568, accompanied by silence ]

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

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

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

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

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

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

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

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

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

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

H>>>Кто может гарантировать что каждую отдельно взятую старую программу писал не лопух?

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

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

то есть, допустим, если изначально при написании программы UB был равен "ничего не случилось", а через 10 лет он вдруг превратился в "process terminated" то виноваты, естественно, разработчики компилятора?

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

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

M_>то есть, допустим, если изначально при написании программы UB был равен "ничего не случилось", а через 10 лет он вдруг превратился в "process terminated" то виноваты, естественно, разработчики компилятора?

В огороде бузина, а в Киеве дядька. Я совсем о другом — о том, что, как правило, лопухи не в состоянии написать программу на С++, которая бы то и дело не падала, а посему ей 10 лет не прожить.

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

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

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

IT>Потому её никто и не использует для перекрывающихся областей.
то есть, чтобы научить людей правильно использовать либы и читать документацию надо выкинуть все проверки из системных функций или натыкать ассертов? Чтобы любой неправильный параметр приводил к смерти? Только так? Ведь, выходит, что если сделали обход потенциальной ошибки, то сами и виноваты, что народ плевал на документацию "не падает, значит, крутой код".

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

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

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

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

IT>Асёрты, исключения, что там у вас в языке программирования С?
согласно доке, она должна портить память. представляю себе такой ассерт

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

IT>>Асёрты, исключения, что там у вас в языке программирования С?
M_>согласно доке, она должна портить память. представляю себе такой ассерт

А с чем проблемы? С адресной арифметикой?

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

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

На моем опыте (большие компании, много закрытого от чужих глаз кода), программы, написанные лопухами на C и других языках, не только не помирают, а живут долго и даже размножаются посредством copy-paste'а. Самому приходилось искоренять такие программы не раз. И хорошо если они еще в младенческом возрасте, таких прибивать легче. Но гораздо чаще это монстры, глубоко пустившие свои корни.

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

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

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

J>а почему не пара то?? если раньше memcpy и memmove делали одно и тоже, то и по идее и инлайнинг работать должен был для них одинаковый результат давать?
да ни разу они одно и то же не делали.
например: простое копирование (memcpy) — это *to == *from; ++to; ++from;
Оно и в ассемблере выглядит почти так же (там будет что-то типа to[i] = from[i]; ++i ).
в то же время если это копирование с пересечением (memmove), то по-хорошему, надо еще и направление копирования выбирать, так, чтобы не затереть кусок источника перед тем, как до него дойдет очеред быть скопированным.

Совсем разные алгоритмы. И, если раньше (допустим) memcpy была реализована как косвенный вызов memmove и прощала пересечения, то если сделать все честно — то ошибки будут стрелять.

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

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

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

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

I>Эдак и про Виндовс можно сказать — ошибки не в Виндовсе а в прикладных программах. Каково ?
не знаю, кто как, а я года с 2002 так считаю: если после какого-то софта система начинает вести себя неправильно, то винда ни при чем. Ибо практический опыт показывает, что качество кода самой винды будет повыше качества окружающего софта.

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

M_>то есть, чтобы научить людей правильно использовать либы и читать документацию надо выкинуть все проверки из системных функций или натыкать ассертов? Чтобы любой неправильный параметр приводил к смерти? Только так? Ведь, выходит, что если сделали обход потенциальной ошибки, то сами и виноваты, что народ плевал на документацию "не падает, значит, крутой код".

Эта функция в libc не выдерживает свои инварианты и сломалась бы на первом юнит-тесте после изменения. Значит, разработчики libc поставляют её "как получилось" или не используют тестирование в своих поделках. Дело тут ведь не в нарушении пользователями документации (это само собой плохо), а в нарушении инвариантов опубликованных функций.

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

Смеялся.
Наглядное свидетельство, что Linux пишут малограмотные обормоты.
Разработчик библиотек не должен поощрять чужое ламерство.
Наоборот, дураков надо учить.

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

Vi2>Эта функция в libc не выдерживает свои инварианты и сломалась бы на первом юнит-тесте после изменения. Значит, разработчики libc поставляют её "как получилось" или не используют тестирование в своих поделках. Дело тут ведь не в нарушении пользователями документации (это само собой плохо), а в нарушении инвариантов опубликованных функций.

Проверки в рантайме чего-то стоят. Не все пользователи системной библиотеки готовы платить эту цену

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

Pzz>Проверки в рантайме чего-то стоят. Не все пользователи системной библиотеки готовы платить эту цену

А причем тут пользователи?

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

Pzz>>Проверки в рантайме чего-то стоят. Не все пользователи системной библиотеки готовы платить эту цену

Vi2>А причем тут пользователи?

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

IT>>>Асёрты, исключения, что там у вас в языке программирования С?
M_>>согласно доке, она должна портить память. представляю себе такой ассерт

IT>А с чем проблемы? С адресной арифметикой?
Рантайм проверка — накладные расходы, оставим на скобками их величину, фишка в том что в коде написанном согласно документации а не "как работает" эта проверка не нужна.
А в дебажном рантайме не помешала бы, да.

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

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

Вопрос в том, можно ли было отдавать ту библиотеку пользователям. Это решается без пользователей. Тестерами. А тут получилось, что всё сообщество стало тестерами.

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

I>Эдак и про Виндовс можно сказать — ошибки не в Виндовсе а в прикладных программах. Каково ?
разработчики винда могут себе позволить Application Compatilibity Database с многими тысячами хаков для таких случаев.

Ш>Смеялся.
Ш>Наглядное свидетельство, что Linux пишут малограмотные обормоты.
Ш>Разработчик библиотек не должен поощрять чужое ламерство.
Ш>Наоборот, дураков надо учить.
Перечитайте исходный пост еще раз тк вы сами себе противоречите.

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

Здесь надо добавить ещё вот что. Функция memcpy -- это не просто ещё одна функция. Это функция, семантика которой известна компилятору.
Т.е. компилятор вместо вызова этой функции вправе сгенерировать эквивалентный код по местоу вызова. Что современные компиляторы так и делают, генерируя более эффективный код.
Т.е. замена реализации в библиотеке может и не исправить ситуцию.
Я не думаю, что для того чтобы удовлетворить малограмотного идиота, нужно жертвовать для всех оптимизирующими способностями компилятора.
Пусть ка этот идиот уберет своё дерьмо сам.

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

Ну здесь проблема скорее из серии маркетинг vs программинг. Без веских причин я бы ничего не менял. Какие были веские причины у разработчиков — хз. Не вижу проблем, почему нельзя было добавить новую функцию.

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

IT>>А с чем проблемы? С адресной арифметикой?
O>Рантайм проверка — накладные расходы, оставим на скобками их величину, фишка в том что в коде написанном согласно документации а не "как работает" эта проверка не нужна.
Я замечу, что memcpy на ассемблере — это (без учета инициализации регистров) одна инструкция.
Так что накладные расходы на рантайм проверку совершенно неприемлемы.

O>А в дебажном рантайме не помешала бы, да.
Для дебажного рантайма есть более суровые инструменты типа всяких electric fence или Valgrind — так что тут все нормально.

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

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

Здравствуйте, Игoрь, Вы писали:

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

И>Ну здесь проблема скорее из серии маркетинг vs программинг. Без веских причин я бы ничего не менял. Какие были веские причины у разработчиков — хз. Не вижу проблем, почему нельзя было добавить новую функцию.
Здесь хорошо сказано почему: http://www.rsdn.ru/forum/philosophy/4036422.aspx

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

DOO>Здравствуйте, Игoрь, Вы писали:

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

И>>Ну здесь проблема скорее из серии маркетинг vs программинг. Без веских причин я бы ничего не менял. Какие были веские причины у разработчиков — хз. Не вижу проблем, почему нельзя было добавить новую функцию.
DOO>Здесь хорошо сказано почему: http://www.rsdn.ru/forum/philosophy/4036422.aspx
И что? У людей то проблемы появились только после явного изменения кода. Даже могу развернуть аргумент в обратную сторону: если многие компиляторы так оптимизируют эту функцию, то зачем вообще было менять?

Я все же думаю, что компиляторы осторожнее оптимизируют даже стандартную библиотеку и работают с реализацией, а не с названием, какие-то реализации инлайнятся в пару инструкций, какие-то — нет. Вообще, не хочу переходить в сугубо техническую часть, потому что проблема здесь в другом: серьезные изменения были внесены через попу. Нужно было: а) провести анализ и понять как много продуктов валятся, принять взвешенное решение; б) объяснить свою мотивацию пользователям; в) о breaking changes следовало бы информировать заранее.

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

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

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

M_>>то есть, допустим, если изначально при написании программы UB был равен "ничего не случилось", а через 10 лет он вдруг превратился в "process terminated" то виноваты, естественно, разработчики компилятора?

PD>В огороде бузина, а в Киеве дядька. Я совсем о другом — о том, что, как правило, лопухи не в состоянии написать программу на С++, которая бы то и дело не падала, а посему ей 10 лет не прожить.

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

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

M_>>то есть, чтобы научить людей правильно использовать либы и читать документацию надо выкинуть все проверки из системных функций или натыкать ассертов? Чтобы любой неправильный параметр приводил к смерти? Только так? Ведь, выходит, что если сделали обход потенциальной ошибки, то сами и виноваты, что народ плевал на документацию "не падает, значит, крутой код".

Vi2>Эта функция в libc не выдерживает свои инварианты и сломалась бы на первом юнит-тесте после изменения. Значит, разработчики libc поставляют её "как получилось" или не используют тестирование в своих поделках. Дело тут ведь не в нарушении пользователями документации (это само собой плохо), а в нарушении инвариантов опубликованных функций.
Думаю, скорее всего у них юнит-тесты проверяют документированный интерфейс. Не должна функция memcpy сохранять живым кусок памяти при копировании пересекающихся блоков — не будет на это юнит-теста. Такой юнит-тест будет у функции memmove. И нельзя оправдываться инвариантами, когда речь идет о наружении контракта фукнции (в котором сказано: работаю только с непересекаюшимися блоками памяти).

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

DOO>Я замечу, что memcpy на ассемблере — это (без учета инициализации регистров) одна инструкция.
DOO>Так что накладные расходы на рантайм проверку совершенно неприемлемы.

Современные компиляторы одну не используют, и не всегда инлайнят. Там довольно сложная функция учитывающая кеш, упреждающую выборку и т. п.
Когда длина известна и небольшая обычно несколькими mov обходятся.
Даже эта "одна" инструкция с REP префиксом по сути цикл.

Здравствуйте, Игoрь, Вы писали:

И>И что? У людей то проблемы появились только после явного изменения кода. Даже могу развернуть аргумент в обратную сторону: если многие компиляторы так оптимизируют эту функцию, то зачем вообще было менять?

Это самый интересный вопрос. Потому что во многих языках подобные функции вообще не являются частью библиотек, а относятся к выражениям самого языка. Здесь сработала низкоуровневость C.

И>проблема здесь в другом: серьезные изменения были внесены через попу. Нужно было: а) провести анализ и понять как много продуктов валятся, принять взвешенное решение;
Я приводил сравнение с протоколами. Сколько сегодня существует реализаций того же TCP — никто никогда не скажет. Если завтра потребуется наконец-то использовать какое-то зарезервированное поле TCP заголовка, то что делать? Никакой хоть сколько-то адекватный анализ провести невозможно. Для glibc это корректное сравнение — она ведь черт знает где используется, никто даже всех дистрибутивов линукса перечислить не сможет.

И>б) объяснить свою мотивацию пользователям; в) о breaking changes следовало бы информировать заранее.
А может это и было сделано?

Вообще, конечно, стоило бы.

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

M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков.

M>Причем некоторые из разработчиков используют это API не описанным в документации способом или даже прямо там запрещенном (не в юридическом смысле) и никаких проблем от этого до сих пор не возникало, потому что, де-факто, оно работало нужным образом, хотя и не позволенным документацией.

M>В один прекрасный момент разработчики чего-то там у себя переписали и внезапно недокументированное поведение функции из API изменилось, что поломало совместимость и привело к ошибкам в работе и возмущениям.

M>И вот кто тут прав?

Для программистов лучше забить на совместимость, для менеджеров важнее customer satisfaction.
Собственно никто не прав или все правы.

Больше влияние менеджеров — больше внимания на такие штуки. Собственно ситуация MS vs Linux.

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

M_>Оно и в ассемблере выглядит почти так же (там будет что-то типа to[i] = from[i]; ++i ).

Нет, там будет одна инструкция ассемблера по копированию блока памяти.

M_>в то же время если это копирование с пересечением (memmove), то по-хорошему, надо еще и направление копирования выбирать, так, чтобы не затереть кусок источника перед тем, как до него дойдет очеред быть скопированным.

Да, а тут разветвление.

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

Ш>Пусть ка этот идиот уберет своё дерьмо сам.

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

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

M_>Думаю, скорее всего у них юнит-тесты проверяют документированный интерфейс. Не должна функция memcpy сохранять живым кусок памяти при копировании пересекающихся блоков — не будет на это юнит-теста. Такой юнит-тест будет у функции memmove. И нельзя оправдываться инвариантами, когда речь идет о наружении контракта фукнции (в котором сказано: работаю только с непересекаюшимися блоками памяти).

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

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

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

Ш>>Пусть ка этот идиот уберет своё дерьмо сам.

IT>Абсолютно согласен. Только в случае с идиотами, разрабатывающими glibc 17 лет назад, во-первых, этих идиотов уже может и не быть, во-вторых, от их дерьма появилось уже много производного дерьма, которое они если и начнут убирать, то очень быстро в нём захлебнутся.

Ты не понял смысла написанного.

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

IT>>Абсолютно согласен. Только в случае с идиотами, разрабатывающими glibc 17 лет назад, во-первых, этих идиотов уже может и не быть, во-вторых, от их дерьма появилось уже много производного дерьма, которое они если и начнут убирать, то очень быстро в нём захлебнутся.

Ш>Ты не понял смысла написанного.

Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению. Дальше это дерьмо всего лишь расползлось по другим приложениям. Я с тобой абсолютно согласен — каждый должен убирать за собой сам. Вот только боюсь, что с тем количеством кала, которое породило решение 1993-го года разработчикам glibc уже не справиться.

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

IT>Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению.
Тут уж мильон раз говорили, что нельзя добавлять такую проверку в функцию, которая реализуется одной инструкцией процессора.

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

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

IT>>>Абсолютно согласен. Только в случае с идиотами, разрабатывающими glibc 17 лет назад, во-первых, этих идиотов уже может и не быть, во-вторых, от их дерьма появилось уже много производного дерьма, которое они если и начнут убирать, то очень быстро в нём захлебнутся.

Ш>>Ты не понял смысла написанного.

IT>Я то как раз понял. А ты видимо не совсем. Могу разжевать.

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

Нет здесь дерьма. Есть функция, поведение которой удовлетворяет требованиям стандарта. Как она работает за пределами своей области определения -- не важно.
Разработчик не обязан за этимм следить. Нечего по этому поводу разводить дискуссию.

IT>Дальше это дерьмо всего лишь расползлось по другим приложениям.

Разработчики библиотеки не несут ответственности за то, что программисты пишут код, нарушая правила языка.
Это первое. Второе, изменение библиотеки под нужды говнокодеров в данном случае, как я объяснил выше, не исправит ситуацию.

Что-то последнее время на RSDN е день тупка какой-то.

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

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

IT>>Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению.
DOO>Тут уж мильон раз говорили, что нельзя добавлять такую проверку в функцию, которая реализуется одной инструкцией процессора.

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

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

IT>>Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению.
Ш>Нет здесь дерьма. Есть функция, поведение которой удовлетворяет требованиям стандарта. Как она работает за пределами своей области определения -- не важно.

Очень даже важно. По исходным кодам библиотке C/C++ компиляторов лично я учился программировать.

Ш>Разработчик не обязан за этимм следить. Нечего по этому поводу разводить дискуссию.

Согласен. Ты, как разработчик не должен. Разработчики glibc обязаны.

IT>>Дальше это дерьмо всего лишь расползлось по другим приложениям.
Ш>Разработчики библиотеки не несут ответственности за то, что программисты пишут код, нарушая правила языка.

Плох тот язык правила которого так легко нарушить.

Ш>Это первое. Второе, изменение библиотеки под нужды говнокодеров в данном случае, как я объяснил выше, не исправит ситуацию.

Говнокодеры в 1993 году написали код, который породил других говнокодеров. Говнокодеры в 2010-ом пытаются из овна слепить другое овно. Лепили бы пулю, было бы понятно. А так...

Ш>Что-то последнее время на RSDN е день тупка какой-то.

Смени сайт, может тупка пройдёт.

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

IT>Плох тот язык правила которого так легко нарушить.
Ну не надо ставить в один ряд управляемые языки и C — его какбы и делали для того, чтобы сохранить свободу на уровне ассемблера, но упростить рутинные операции.
Если ты помнишь времена Borland C 3.1, то там, например, можно было фактически все — управляемость линкера и компилятора была просто поразительной.
А кому надо жесткие ограничения — добро пожаловать в мир управляемых языков со всеми вытекающими ограничениями.

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

IT>>Я то как раз понял. А ты видимо не совсем. Могу разжевать. Первое дерьмо появилось в 1993 году в функции, которая позволяла себя использовать не по назначению.
DOO>Тут уж мильон раз говорили, что нельзя добавлять такую проверку в функцию, которая реализуется одной инструкцией процессора.

http://www.rsdn.ru/forum/philosophy/4036954.1.aspx

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

Ш>Тут дело даже не в этом. Человек пишет код. У него есть требования на реализацию, кроме того, он должен написать данную функцию максимально эффективно.
Ш>Как при этом будет работать данная функция, если её неправильно используют, его волновать не должно совершенно. Как получится, поведение не определено в этом случае.

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

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

FR>Современные компиляторы одну не используют, и не всегда инлайнят. Там довольно сложная функция учитывающая кеш, упреждающую выборку и т. п.
FR>Когда длина известна и небольшая обычно несколькими mov обходятся.
FR>Даже эта "одна" инструкция с REP префиксом по сути цикл.

Давай конкретней, про какие компиляторы речь. А то для MS VC всё что ты написал — неверно.

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

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

Гонишь ведь.

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

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

M_>>Думаю, скорее всего у них юнит-тесты проверяют документированный интерфейс. Не должна функция memcpy сохранять живым кусок памяти при копировании пересекающихся блоков — не будет на это юнит-теста. Такой юнит-тест будет у функции memmove. И нельзя оправдываться инвариантами, когда речь идет о наружении контракта фукнции (в котором сказано: работаю только с непересекаюшимися блоками памяти).

Vi2>К тому же, и у memcpy, и у memmove будут одинаковые тесты.
почему? Точнее, зачем в тесты для memcpy совать тест на правильную обработку пересекающихся областей? А потом еще проверять, чтобы он сломался? Ибо он может сломаться, а может и не сломаться (ибо в контракте не оговорено, что должно произойти).

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

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

M_>>Оно и в ассемблере выглядит почти так же (там будет что-то типа to[i] = from[i]; ++i ).

V>Нет, там будет одна инструкция ассемблера по копированию блока памяти.
ну да. примерно такой цикл она и будет выполнять, только со счетом от значения ECX до 0. Если со времен 386 процессора не появилось принципиально новых команд в основной линейке.

Я со времен универа ассемблером не осень занимаюсь.

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

FR>>Современные компиляторы одну не используют, и не всегда инлайнят. Там довольно сложная функция учитывающая кеш, упреждающую выборку и т. п.
FR>>Когда длина известна и небольшая обычно несколькими mov обходятся.
FR>>Даже эта "одна" инструкция с REP префиксом по сути цикл.

V>Давай конкретней, про какие компиляторы речь. А то для MS VC всё что ты написал — неверно.

Как раз для VC все справедливо, находишь memcpy.asm практически я ее выше и описал.

Вот такой код:

#include <stdio.h>
#include <memory.h>
#include <string>
#include <vector>

int main()
{
wchar_t Dst[10];

// Для фиксированной небольшой длины.
wchar_t *a0 = L"Test";
memcpy(Dst, a0, 5 * sizeof(wchar_t));
printf("%S\n", Dst);

// Неизвестная при компиляции длина
std::wstring a1 = L"TesT";
memcpy(Dst, a1.c_str(), (a1.size() + 1) * sizeof(wchar_t));
printf("%S\n", Dst);
}

для VC 2009 c /O2 дает такой выхлоп:

_main    PROC                        ; COMDAT

; 7    : {

    sub    esp, 52                    ; 00000034H
    mov    eax, DWORD PTR ___security_cookie
    xor    eax, esp
    mov    DWORD PTR __$ArrayPad$[esp+52], eax

; 8    : wchar_t Dst[10];
; 9    : 
; 10   : // Для фиксированной небольшой длины.
; 11   : wchar_t *a0 = L"Test";
; 12   : memcpy(Dst, a0, 5 * sizeof(wchar_t));

    mov    eax, DWORD PTR ??_C@_19FNGKFHMA@?$AAT?$AAe?$AAs?$AAt?$AA?$AA@
    mov    ecx, DWORD PTR ??_C@_19FNGKFHMA@?$AAT?$AAe?$AAs?$AAt?$AA?$AA@+4
    mov    dx, WORD PTR ??_C@_19FNGKFHMA@?$AAT?$AAe?$AAs?$AAt?$AA?$AA@+8
    mov    DWORD PTR _Dst$[esp+52], eax
    push    esi

; 13   : printf("%S\n", Dst);

    lea    eax, DWORD PTR _Dst$[esp+56]
    push    eax
    push    OFFSET ??_C@_03NNECAHIM@?$CFS?6?$AA@
    mov    DWORD PTR _Dst$[esp+68], ecx
    mov    WORD PTR _Dst$[esp+72], dx
    call    _printf

; 14   : 
; 15   : // Неизвестная при компиляции длина
; 16   : std::wstring a1 = L"TesT";

    xor    ecx, ecx
    add    esp, 8
    lea    eax, DWORD PTR [ecx+4]
    lea    esi, DWORD PTR _a1$[esp+56]
    mov    DWORD PTR _a1$[esp+80], 7
    mov    DWORD PTR _a1$[esp+76], 0
    mov    WORD PTR _a1$[esp+60], cx
    call    ?assign@?$basic_string@_WU?$char_traits@_W@std@@V?$allocator@_W@2@@std@@QAEAAV12@PB_WI@Z ; std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >::assign

; 17   : memcpy(Dst, a1.c_str(), (a1.size() + 1) * sizeof(wchar_t));

    mov    eax, DWORD PTR _a1$[esp+60]
    mov    esi, 8
    cmp    DWORD PTR _a1$[esp+80], esi
    jae    SHORT $LN49@main
    lea    eax, DWORD PTR _a1$[esp+60]
$LN49@main:
    mov    edx, DWORD PTR _a1$[esp+76]
    lea    ecx, DWORD PTR [edx+edx+2]
    push    ecx
    push    eax
    lea    edx, DWORD PTR _Dst$[esp+64]
    push    edx
    call    _memcpy

; 18   : printf("%S\n", Dst);

    lea    eax, DWORD PTR _Dst$[esp+68]
    push    eax
    push    OFFSET ??_C@_03NNECAHIM@?$CFS?6?$AA@
    call    _printf
    add    esp, 20                    ; 00000014H

; 19   : }

    cmp    DWORD PTR _a1$[esp+80], esi
    pop    esi
    jb    SHORT $LN78@main
    mov    ecx, DWORD PTR _a1$[esp+56]
    push    ecx
    call    ??3@YAXPAX@Z                ; operator delete
    add    esp, 4
$LN78@main:
    mov    ecx, DWORD PTR __$ArrayPad$[esp+52]
    xor    ecx, esp
    xor    eax, eax
    call    @__security_check_cookie@4
    add    esp, 52                    ; 00000034H
    ret    0
_main    ENDP

В общем все как я и говорил.

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

DOO>Это самый интересный вопрос. Потому что во многих языках подобные функции вообще не являются частью библиотек, а относятся к выражениям самого языка. Здесь сработала низкоуровневость C.
Не имеет значения, схожая проблема могла возникнуть с любым языком.

DOO>Я приводил сравнение с протоколами. Сколько сегодня существует реализаций того же TCP — никто никогда не скажет. Если завтра потребуется наконец-то использовать какое-то зарезервированное поле TCP заголовка, то что делать? Никакой хоть сколько-то адекватный анализ провести невозможно. Для glibc это корректное сравнение — она ведь черт знает где используется, никто даже всех дистрибутивов линукса перечислить не сможет.
Да, для полноты картины только аналогий с tcp не хватало. В следующий раз пусть ко мне обращаются, я им происследую без проблем

И>>б) объяснить свою мотивацию пользователям; в) о breaking changes следовало бы информировать заранее.
DOO>А может это и было сделано?

DOO>Вообще, конечно, стоило бы.
Хз, но судя по первому сообщению не похоже.

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

M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков.
M>Причем некоторые из разработчиков используют это API не описанным в документации способом или даже прямо там запрещенном (не в юридическом смысле) и никаких проблем от этого до сих пор не возникало, потому что, де-факто, оно работало нужным образом, хотя и не позволенным документацией.
M>В один прекрасный момент разработчики чего-то там у себя переписали и внезапно недокументированное поведение функции из API изменилось, что поломало совместимость и привело к ошибкам в работе и возмущениям.
M>И вот кто тут прав?

Разработчики, которые использовали функцию, нарушая контракт, однозначно долбодолбы. Но исправлять ситуацию все равно придется разработчикам glibc. Как бы ни хотелось поставить дебилов на место, но суровая реальность такова, что ПО создается для конечных пользователей. И не важно по каким причинам оно перестанет работать, в мозгах отложится "Новый линукс не совместим со флешем". Заставить сонмище говнокодеров следовать спецификациям и переписать свои поделки за неделю нереально.

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

D>Разработчики, которые использовали функцию, нарушая контракт, однозначно долбодолбы.

Вас можно поздравить — судя по всему Вы давно забыли о том, что такое баги и разогнали отдел тестирования? ))
На самом же деле это чистая статистика. Если есть возможность использовать что-то неправильно, и это что-то используется достаточно широко, то оно будет использовано неправильно. Даже не по злой воле неких долбодолбов, а просто потому, что человеку свойственно ошибаться.

Здравствуйте, Кодёнок, Вы писали:

Кё>Единственный косяк со стороны glibc — отсутствие предупреждения о внесении ломающих изменений. Впрочем, они не майкрософт, у них нет целого отдела, тестирующего на совместимость — могли просто не знать. В остальном, разработчики ПО сами себе продемонстрировали свою же поговорку: “читайте доки, они рулез”

Хотя если подумать, еще дебажная версия memcpy могла бы проверять контракт, на всякий случай.

Здравствуйте, Кодёнок, Вы писали:

Кё>В остальном, разработчики ПО сами себе продемонстрировали свою же поговорку: “читайте доки, они рулез”

Все здесь такие непогрешимые, что я даже удивляюсь, зачем вообще такая профессия как тестер нужна? Казалось бы, проще некуда — прочитали доки и написали софт ))

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

D>>Разработчики, которые использовали функцию, нарушая контракт, однозначно долбодолбы.
COF>Вас можно поздравить — судя по всему Вы давно забыли о том, что такое баги и разогнали отдел тестирования? ))

Не понял связи. Баги надо исправлять, а не обвинять разработчиков core API, что они вовремя не отшлепали тех, кому плевать на явное указание в документации, что таким способом функцию использовать нельзя.

COF>На самом же деле это чистая статистика. Если есть возможность использовать что-то неправильно, и это что-то используется достаточно широко, то оно будет использовано неправильно. Даже не по злой воле неких долбодолбов, а просто потому, что человеку свойственно ошибаться.

То есть запрещаем молотки только потому, что есть некоторые люди, которые будут бить им по пальцам, а не по гвоздям?
Я так понимаю, это был намек, что разработчики glibc должны были сделать проверку правильности аргументов. А вот теперь вопрос: должны ли разработчики одной из основных функций ядра максимально ее оптимизировать, или же они должны позаботиться об особо одаренных, кто не в состоянии понять документацию, и добавить все возможные проверки (учти, что данный конфликт учитывает только один из возможных неправильных вариантов значений аргументов)?
И еще вопрос: как бы вы оценивали ситуацию, если бы разработчики Flash'а в свое время прочитали бы документацию и с новой версией glibc не было проблем? Вам не кажется, что вопроса то не было бы, а всех остальных просто отправили бы выпускать новые версии своего ПО под новую версию glibc, как это делает Микрософт со многими продуктами?

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

D>То есть запрещаем молотки только потому, что есть некоторые люди, которые будут бить им по пальцам, а не по гвоздям?
D>Я так понимаю, это был намек, что разработчики glibc должны были сделать проверку правильности аргументов. А вот теперь вопрос: должны ли разработчики одной из основных функций ядра максимально ее оптимизировать, или же они должны позаботиться об особо одаренных, кто не в состоянии понять документацию, и добавить все возможные проверки (учти, что данный конфликт учитывает только один из возможных неправильных вариантов значений аргументов)?

Почему все сводится к пониманию документации? Я могу прекрасно знать, что в memcpy нельзя передавать пересекающиеся области памяти, но я могу банально пропустить ситуацию, когда две области все-таки пересекаются, хотя мне кажется совсем иначе. Найти и исправить эту ошибку практически невозможно. А так как продолжалась эта ситуация достаточно долго, то и вероятность того, что эта ошибка проявится была высокой. Кстати, именно во Flash'е она проявилась только потому, что его много кто использует, а не потому, что он плохо написан. Наверняка она есть и во многих других местах, просто пока ее не нашли. Виноваты в этом только разработчики glibc — это классическая ситуация типа "мы в ответе за тех, кого приручили". По моему, они поступили абсолютно безответственно. Почему, например, нельзя было ввести какой-то define типа FAST_MEMCPY и вызывать старую или новую функцию в зависимости от него? Кому надо, тот его поставит, а старый код работал бы без изменений.

Типичный догматичный за@б линупсоидов — поставить раком собственных юзеров из-за того, что индокодеры священные маны не читали.
Что бы сделал пыщьх? Элементарно:
1. На уровне ~~молока матери~~ билд-системы разделение на DEBUG и RELEASE билды, вместо самописных велосипедов в половине make-файлов.
2. За год до изменения модифицируем debug-версию memcpy(), чтобы там вылетал ASSERT() в случае пересекаюшихся буферов.
3. Даем девелоперам год на фикс. Пишем об этом явно и везде.
4. Спустя год, меняем release-реализацию.

Но, почему-то, в сообществе красноглазиков думать о юзабилити не принято. Так что, слушайте, Василий Иванович, ваши валенки...

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

COF>Почему все сводится к пониманию документации? Я могу прекрасно знать, что в memcpy нельзя передавать пересекающиеся области памяти, но я могу банально пропустить ситуацию, когда две области все-таки пересекаются, хотя мне кажется совсем иначе.

Давно не писал на ся, так что малость не в курсе современных методик разработки. Но судя по форумам и применяя здравый смысл, могу предположить, что как минимум можно сделать свою обертку над memcpy, где и проводить свою проверку непересечения областей. Эту обертку можно обложить юнит-тестами.
Насколько я знаю, немало сишных проектов, где присутствует свой менеджер памяти как раз для того, чтобы не огрести проблем. Разработчики из Адоба этим не озаботились.
Так что, извините за грубость, им можно сказать только одно: "Не можешь срать — не мучай жопу". В смысле, если не в состоянии грамотно писать на си и уследить за памятью, то переквалифицируйся на сишарп или яву, там таких проблем с не будет (хотя могут быть другие, и если избегать нормального процесса тестирования, они будут).

COF>Кстати, именно во Flash'е она проявилась только потому, что его много кто использует, а не потому, что он плохо написан. Наверняка она есть и во многих других местах, просто
пока ее не нашли. Виноваты в этом только разработчики glibc — это классическая ситуация типа "мы в ответе за тех, кого приручили". По моему, они поступили абсолютно безответственно.

Это называется перекладывание ответственности. "Меня не научили", "мне не сказали", "я про это не читал". Как уже писал выше, конечные разработчики ПО вполне могли создать свои обертки над системными вызовами, где и проводить все проверки.

COF>Почему, например, нельзя было ввести какой-то define типа FAST_MEMCPY и вызывать старую или новую функцию в зависимости от него? Кому надо, тот его поставит, а старый код работал бы без изменений.

Подозреваю, так и сделают.

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

COF>>Кстати, именно во Flash'е она проявилась только потому, что его много кто использует, а не потому, что он плохо написан. Наверняка она есть и во многих других местах, просто пока ее не нашли. Виноваты в этом только разработчики glibc — это классическая ситуация типа "мы в ответе за тех, кого приручили". По моему, они поступили абсолютно безответственно.

D>Это называется перекладывание ответственности. "Меня не научили", "мне не сказали", "я про это не читал". Как уже писал выше, конечные разработчики ПО вполне могли создать свои обертки над системными вызовами, где и проводить все проверки.

Не понял. По вашему, надо каждый системный вызов обертывать и параноидально проверять на возможность некорректного использования?

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

D>>Это называется перекладывание ответственности. "Меня не научили", "мне не сказали", "я про это не читал". Как уже писал выше, конечные разработчики ПО вполне могли создать свои обертки над системными вызовами, где и проводить все проверки.

S>Не понял. По вашему, надо каждый системный вызов обертывать и параноидально проверять на возможность некорректного использования?

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

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

Конечно шутка, но в каждой шутке... Ну нельзя требовать от людей постоянно помнить кучу деталей. В конце концов можно банально спутать эти две функции. Помнить, что они разные, но вот попутал бес и был уверен, что наоборот. А по названию тут хрен догадаешься. Или не подумал (думал о другом). Опять же, кроме чтения документации можно глянуть исходник.

Гуманнее надо быть к людям и прощать их ошибки. Тем более, когда это ничего не стоит.

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

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

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

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

S>Не понял. По вашему, надо каждый системный вызов обертывать и параноидально проверять на возможность некорректного использования?

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

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

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

S>>Не понял. По вашему, надо каждый системный вызов обертывать и параноидально проверять на возможность некорректного использования?

M>Скорее речь идет об отладочной версии glibc, где предусмотреть создание лога предупреждений.

Я понял Донца, что пользователи сами должны делать себе такие версии glibc и прочего. А это ИМХО перебор

Я не понмаю проблемы .

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

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

DOO>Я замечу, что memcpy на ассемблере — это (без учета инициализации регистров) одна инструкция.
DOO>Так что накладные расходы на рантайм проверку совершенно неприемлемы.
К сожалению, уже лет 10 как попытка сделать "memcpy на ассемблере" в одну инструкцию породит больше накладных расходов, чем в несколько. Все приличные компиляторы выполняют развёртку цикла, и она работает быстрее, чем rep movsd.
Крайне не рекомендую учить матчасть в 2010 году по книге "ассемблер 386 для профессионалов".

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

V>Нет, там будет одна инструкция ассемблера по копированию блока памяти.
Нет. Там будет довольно много инструкций.

Здравствуйте, March_rabbit, Вы писали:
V>>Нет, там будет одна инструкция ассемблера по копированию блока памяти.
M_>ну да. примерно такой цикл она и будет выполнять, только со счетом от значения ECX до 0. Если со времен 386 процессора не появилось принципиально новых команд в основной линейке.

Я со времен универа ассемблером не осень занимаюсь.
Дело не в новых командах, а в новой архитектуре. И во времена твоего универа rep movs* была ничуть не быстрее по тактам, чем ручное написание цикла. А сейчас развёртывание цикла позволяет существенно сэкономить. Современные компиляторы практически никогда не используют префикс rep.

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

M>Предположим есть некий давно присутствующий на рынке программный продукт, с API, которое использует огромное число разработчиков...

Я считаю что в данном случае виноваты разработчики API, в частности реализовавшие memcpy, правильно работающей и с перекрывающимися блоками, т.к. это расходится с документацией, но вызов требует больших затрат времени ЦПУ чем простое копирование, т.к. требует дополнительных проверок. Следовательно, если это свойство широко используется, значит его нужно сохранить. А подобное поведение разработчиков glibc похоже вызвано тем что они чувствуют себя пупом земли. Думаю если это продолжится, или всплывут другие такиеже случаи, то glibc будет иметь альтернативные сборки.

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

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

И после этого кто-то агитирует за линукс на десктопе в реальной жизни. В следующий раз сломают гуй и скажут, "ну и гуй с ним".

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

S>Я считаю что в данном случае виноваты разработчики API, в частности реализовавшие memcpy, правильно работающей и с перекрывающимися блоками, т.к. это расходится с документацией, но вызов требует больших затрат времени ЦПУ чем простое копирование, т.к. требует дополнительных проверок.

Дополнительных проверок как раз не было, они просто тупо mov-или, продвигаясь сверху вниз по адресам. А потом им пришло в голову использовать векторные инструкции процессора для ускорения.

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

S> Следовательно, если это свойство широко используется, значит его нужно сохранить.

Вот это и есть камень преткновения: стоит или нет. Как видно, имеются доводы и за и против. С одной стороны, такое поведение де-факто похоже с самых первых версий линукса, с другой стороны — все-таки никто не обещал правильного поведения во всех случаях.

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

А и так уже были или есть.

	От:	Michael7
	Дата:	11.11.10 09:17
	Оценка:	40 (9) +1

От:	Aen Sidhe	Просто блог
Дата:	11.11.10 09:23
Оценка:	+3

	От:	DOOM
	Дата:	11.11.10 09:25
	Оценка:	+13

От:	Sshur	http://shurygin-sergey.livejournal.com
Дата:	11.11.10 09:36
Оценка:	+3

	От:	Мишень-сан
	Дата:	11.11.10 11:06
	Оценка:

От:	Anton Batenev	https://github.com/abbat
Дата:	11.11.10 11:45
Оценка:

От:	IT	linq2db.com
Дата:	11.11.10 14:55
Оценка:	+7 -14

От:	Pzz	https://github.com/alexpevzner
Дата:	11.11.10 15:07
Оценка:

От:	rsn81	http://rsn81.wordpress.com
Дата:	11.11.10 16:38
Оценка:	5 (2) +4

От:	hardcase	http://nemerle.org
Дата:	11.11.10 16:49
Оценка:

	От:	Pavel Dvorkin
	Дата:	11.11.10 17:42
	Оценка:	+1

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	11.11.10 18:08
Оценка:	+2 -3

От:	мыщъх	http://nezumi-lab.org
Дата:	11.11.10 18:23
Оценка:

От:	SchweinDeBurg	http://zarezky.spb.ru/
Дата:	12.11.10 06:55
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	12.11.10 11:17
Оценка:

От:	Vi2	http://www.adem.ru
Дата:	12.11.10 19:57
Оценка:	-1

От:	Donz	http://donz-ru.livejournal.com
Дата:	16.11.10 08:26
Оценка:	+5 -1

От:	пыщьх	http://rsdn_user.livejournal.com
Дата:	16.11.10 21:57
Оценка:	2 (1) +10

От:	Mystic	http://mystic2000.newmail.ru
Дата:	17.11.10 11:29
Оценка:	-1

От:	Sinclair	https://github.com/evilguest/
Дата:	24.12.10 14:54
Оценка:	+1

От:	WinterMute	http://yarrr.ru
Дата:	31.03.11 12:27
Оценка: