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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

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

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

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

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

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