если допустима ошибка,

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

но требуется быстродействие

./configure --disable-all-this-bugchecks

или по либе на каждую программу?

Предельное быстродействие, если оно реально требуется, требуется не «программе», а программно-аппаратному комплексу в целом. Если уж никак не укладываешься с проверками, значит пересоберешь релизный код без проверок. Но нет никаких причин не проводить проверок на типичном десктопе.

Я нипадеццки прусь с Улриха: как пукнет

А я прусь с тех, кто считает «пуком» удаление живой архитектуры.

Дреппер — упоротый [мч]удак. Ладно еще забить на итаниумный код и написать в чейнджлог что-то вроде «IA-64 больше не поддерживается, если что — ковыряйтесь сами», но преднамеренно УДАЛЯТЬ кучу работающего кода... Причем ведь не #ifdef-ы же какие-нибудь, избыток которых затрудняет восприятие/чтение кода, а никому (кроме Дреппера) не мешающие файлы в отдельной директории. Ппц, блджад.

Да если даже разработчики glibc и не совсем правильно сделали, то это не оправдывает adobe, которые внаглую проигнорировали требования, указанные в документации. Можно, конечно, говорить, что нужно было, чтобы выдавалась ошибка, но тут опять же то не оправдывает это. Может, ещё скажете, что glibc должна сама программы писать, раз кто-то это не умеет делать?

Я тебе ещё четыре часа назад сказал что это самая здравая идея которая у тебя есть.

Я тебе лучше вот что скажу: если посмотреть на сырцы ядра то ты там увидишь сотни костылей для обхода различных багов в прогах. Если ты откроешь сырцы glibc то ты найдёшь 100500 костылей для ядра и дурных прог.

Так вот, угадай с трёх раз сколько уже было багов из-за попытки сделать совместимость с кривым (в частности бинарным софтом). Да дофейхуа. Это помимо того что исходники местами превратились в говно.

Вот прямо щас иди и грепай по grep -i «workaround» в сырцах и наслаждайся. Там ещё ко многим каменты есть когда эти костыли приводят к проблемам (это к вопросу «могу ли я поручиться что больше глючных прог нет») с комментами типа «надеемся этого в жизни не случится».

Типичный тред этого мудака. Зацените. :D http://sourceware.org/bugzilla/show_bug.cgi?id=4980

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

Ты видел тот код? Вносим ошибку в 2 шага:

1) Используем правильно memcpy 2) Делаем копируемые области пересекающимися.

(1) и (2) делают разные люди, причём (2) может быть достаточно нетривиальным и не просмотреть весь остальной код на правильность использования. Юнит тесты прогнали - всё ок.

Кстати, куда вас пошлёт адоб, если вы к ним обратитесь по поводу этого бага? Правильно - куда подальше, ибо у них записано - поддерживается дистрибутив A, версии X.Y.Z и работу в нём, мы гарантируем. А если вы умудрились наш код ещё где-то запустить, то это уже ваши проблемы.

если посмотреть на сырцы ядра то ты там увидишь сотни костылей для обхода различных багов в прогах. Если ты откроешь сырцы glibc то ты найдёшь 100500 костылей для ядра и дурных прог.

громко, а пруф можна?

громко, а пруф можна?

Сделай grep по glibc.

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

По словам workaround, work around, bug, dirty hack, XXX, etc.

попыток использования UB

Я слегка вторгнусь в ваш разговор. Что такое UB?

если посмотреть на сырцы ядра то ты там увидишь сотни костылей для обхода различных багов в прогах. Если ты откроешь сырцы glibc то ты найдёшь 100500 костылей для ядра и дурных прог.

Не срача ради, а знаний и опыта - хотя бы один такой костыль покажи, пожалуйста, в ядре и в glibc.

Как ни странно, будут виноваты именно вирусы (точнее, их авторы)

Ну пользователя никто не заставлял ставить такую библиотеку в систему, в которой из-за UB из-под простого пользователя можно корневой раздел снести. Если он решил поставить такую библиотеку, то должен понимать последствия.

В случае с memcpy/memmove особенности чётко прописаны в стандарте. Если разработчик не умеет читать документацию, он выбрал неправильную профессию. UB понятно какое — само по себе диск неотформатирует. В общем, старый добрый принцип purgamentum init, exit purgamentum.

Если уж продолжать неуместные аналогии, то у лекарств имеются летальные дозы. Производитель честно пишет, какая доза допустима. При передозировке, грубо говоря, возникает undefined behavior. Если пациент проигнорировал инструкцию, туда ему и дорога. Но виноват-то не производитель лекарства?

Не срача ради, а знаний и опыта - хотя бы один такой костыль покажи, пожалуйста, в ядре и в glibc.

Обходы аппаратных багов не устроят?

Взять и уебать, простите за мат

Анон прав - он, судя по его коментам - феерический долбоеб.

Вопрос.

Petr Baudis 2007-09-23 20:59:16 UTC

I have tried to search the web already and found nothing. If you want to close
bugs as INVALID/WORKSFORME, please provide a proper explanation.

Ответ

Ulrich Drepper 2007-09-23 22:42:21 UTC

Strange, I never saw your name on my paycheck.  Since if that's not the case you
cannot order me around.

Да любые, только с __FILE__ и __LINE__ и, если можно, пояснением, в чем суть костыля.

А я прусь с тех, кто считает «пуком» удаление живой архитектуры.

Во-первых, Сцецальная Олимпиала, что по пуку, что не по пуку, что по Очень Важному Поводу — была и остается Спецальной Олимпиадой.

Во-вторых, действительно стоит уточнить формулировки. Удаление целой немер^W«живой» архитектуры действительно следует считать Очень Громким Пуком.

Просто я как-то раз наблюдал как бригаду таких вот «ульрихов» равли в клочки на совещании руководителей филиалов. И этого однажды порвут. А коль не порвут — так заигнорят. Его уже фактически заигнорили, судя по списку рассылки куда он свои мудрые пу^W мысли пишет почти единолично.

Что такое UB, что вы тут все дружно обсуждаете?

Видел баг, закрепленный за Ульрихом? ПОчитай его ответы - это пиздец. http://sourceware.org/bugzilla/show_bug.cgi?id=4980

то доктор из соображений гуманизма должен вам назначить тазик-эвтаназик

Не заставляйте меня верить, что Дарвин всё-таки был прав.

Таким идеалистичным людям

Идеалист — тот, кто умеет читать спецификации и понимать написанное?

Зайди в drivers/ata и сделай grep around *.c; команда выдаст тебе кучу всего, даже со ссылками на errata устройств.

Что такое UB, что вы тут все дружно обсуждаете?

Undefined Behaviour

Gracefully обрабатывать UB — первый признак культуры программирования.

Знаете разницу между умным человеком и мудрым человеком? Вот и здесь точно также: культурный программист *не будет* допускать undefined behavior.

Неужели в glibc нету какой-нибудь архитектуры типа «standard c» без всяких ассемблерных оптимизаций?

libc в любом случае завязан на многие низкоуровневые вещи. Хотя бы код, дергающий сисколлы, будет на ассемблере.

Сцецальная Олимпиала, что по пуку, что не по пуку, что по Очень Важному Поводу — была и остается Спецальной Олимпиадой.

А небыдло всегда остается небыдлом.

ты всё так же упорот. «за пределами стандарта» жизни быть не должно, особенно когда есть другая функция которая покрывает то самое «за пределами стандарта».

Вообще, не вижу особого смысла в memcpy. Оно не намного быстрее memmove.

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

хотя бы один такой костыль покажи, пожалуйста, в ядре и в glibc.

Напомни завтра, щас с ходу не нахожу то эпичное место. Оно было или в районе fork или pae.

ok

Вообще, не вижу особого смысла в memcpy.

это вопрос из другой плоскости. Я тоже не особо дёргаюсь по поводу скорости. Если она так уж важна то свой вариант memcpy пишется на асме за 10 минут (а ещё лучше тупо копируется ибо в инете столько их, многие с бенчмарками).

Там, емнип, направлений копирований зависило от конкретной модели процессора и выбиралось в рантайме. Короче, жуткое усложнение неизвестно зачем.

На одних процессорах копировать быстрее в одном направлении, на других - в другом. Очевидно же, не?

А небыдло всегда остается небыдлом.

Ну, знаешь, вообще-то небыдло — абстракция суть. Наводе модели OSI. А жизнь намного ... мне-э-э-э... красочнее.

За каким-то хреном кинулись обсуждать природу UB. Хотя UB к данному ... э-э-э-э ... действию ... Ульриха ну никакого отношения не имеет. И дадно бы хоть на каком-то выскоком нравственном уровне... Ведь на уровне двух инженеров, спорящих о стратегии закручивания шурупов: сначала «закручивать сколько закручивается», а потом «забивать сколько забивается» или наоборот. Право же.

vova7890, bk_, я вспомнил. Щас не нахожу с ходу, но это в том месте где приоритет задач задавался. Может уже кусок выпилили, щас лень искать.

Я расскажу как было дело. В общем, приоритет не всегда задавался от -19 до +20 (вроде в posix вообще диапазон не указан, но могу тут наврать за давностью лет). Внутри шедулера был свой диапазон (вроде 0 до 100 или типа того). Однако наружу такой диапазон не выставишь, поэтому производились какие-то пересчёты. Причём код был размазан на glibc и на ядро. И в итоге вышла что при некоторых комбинациях версий ядра и glibc всё это страшно глючило, поэтому там чуть ли не для каждой версии glibc была своя версия функции. В общем, где-то в райное sched_get_priority_max/sched_get_priority_min куча лабуды была.'

В общем, допрыгались с воркэраундами для софта который не понимает приоритеты за границами [-19;20].

На одних процессорах копировать быстрее в одном направлении, на других - в другом. Очевидно же, не?

Да, но только никто так и не сумел подтвердить это. В списках рассылки Линус писал, что у него разницы нету.

ЗЫ вот интересная инфа от ребят из интел http://software.intel.com/en-us/articles/memcpy-performance/ на x86_64 тривиальная реализация memcpy циклом под gcc работает быстрее, чем ассемблерный код в glibc :3 (статья правда 2009-ого года)

Да, но только никто так и не сумел подтвердить это.

Кроме авторов

В списках рассылки Линус писал, что у него разницы нету.

Линус давно стал треплом

Intel все еще продолжает активную разработку IA64, а HP использует ее в собственных операционных системах HP-UX и OpenVMS, к тому же, Huawei и Inspur в апреле прошлого года приняли решение использовать процессоры Itanium в серверах собственной сборки
Линукскапец.

Кроме авторов

Когда меня этот вопрос заинтересовал, я так и не нашел пруфлинк.

Кстати, из самого названия функции memcpy следует, что она КОПИРУЕТ участок памяти. А само слово «копирование» подразумевает, что исходные данные остаются неизменными. А в случае пересекающихся фрагментов они точно изменятся. Так что даже само название функции говорит, что использовать её для пересекающихся фрагментов неправильно.

По-моему, в багзилле было

Ulrich Drepper
Это тот самый, что писал „Stop reopening!!!11” стопицот раз в том эпичном треде? Не взлетит.

Тот тред - просто эталон дорвавшегося до программирования жадного школьника.

Там ему даже $1 перечислили на пейпал.

Itanium не нужен.

Itanium не нужен.

ты опоздал на 4 страницы

http://memegenerator.net/cache/instances/400x/12/12706/13011242.jpg
Не удержался.

Разумеется!

Тот, кто юзает UB, тот тупой ССЗБ!

Тот, кто юзает UB, тот тупой ССЗБ!

Ты сделал мой день, анонимный брат.

я не поверю, я под маки программы писал

только на мелких блоках. иначе movaps зарулит.

Только он там был прав (как обычно), а объяснение действительно было сложным. Так что он просто не хотел тратить время на надоедливых людей, не приносящих ему прямой пользы — примерно, как Гоблин, чей сленг Вы используете.

Да вообще-то насчёт IA-64 всё правильно сделал. Itanium мало кому нужен - архитектура слишком сложная, чтобы написать средства разработки для эффективного её использования.

Наверно среди разработчиков glibc есть пользователи Alpha.