Откуда это «user don't care»?

Юзерам глубоко пофиг на IT и около IT темы, и это не делает их быдлом.

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

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

Кто виноват - криворукие жадные строители или цементный завод, не предусмотревший того, что эти строители нарушают нормы при строительстве?

И эта история - реальный случай

Нет, не так. Строители сказали: «Мы вам отремонтируем дом до новой версии 3.11». Жители сказали: «ОК». Зимой дом развалился. Кто виноват: те, кто ремонтировал дом, или те, кто строил предыдущую версию дома и не предусмотрел, что именно могут сломать при ремонте?

Мы вам построим отремонтируем дом до новой версии 3.11

я не распарсил

Нет, не так. Если продукт один, то тут еще возможно такое толкование. Но тут продуктов 2: glibc и flash player. разработчики glibc сделали все правильно (аналог цементного завода из моего рассказа). но вылезли баги адобовцев строителей (аналог быдло-строителей).

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

Прочитал простыню одним словом: gentoo =D

Но тут продуктов 2: glibc и flash player. разработчики glibc сделали все правильно (аналог цементного завода из моего рассказа). но вылезли баги адобовцев строителей (аналог быдло-строителей).

Ну вот, кривая аллегория подобна нефритовому слону. Ты когда-нибудь такое видел, чтобы в фундаменте дома, не трогая самого дома, заменяли цемент? А если бы и сделали такое, кого бы жильцы начали винить: строителей дома или заменяльщиков цемента?

Или обновление glibc — это в твоей аллегории зима? Так зиму не производят на цементном заводе. Её производят на специальных фабриках в Клаудсдейле.

Прочитал простыню одним словом: gentoo =D

И сидишь на gentoo ?

И сидишь на gentoo ?

Ыгы.

Ты когда-нибудь такое видел, чтобы в фундаменте дома, не трогая самого дома, заменяли цемент?

Но зато под кучей однотипных домов с общим багом бывают разные грунты. А сами дома одинаковы. Так что произошла замена грунта под типовым домом

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

У нас, в соседней мухосрани, кстати, такое было. Дошли до завода.

В этой ситуации была угроза жизни. А кривой драйвер Nvidia или флеш - это «okay, пойду поем» для любого нормального человека

В данной ситуации не было угрозы.

разработчики glibc сделали все правильно (аналог цементного завода из моего рассказа). но вылезли баги адобовцев строителей (аналог быдло-строителей).

Есть другое мнение, во избежание бесконечного перевода стрелок, posix не должен содержать непредвиденного поведения.

Это не posix, а стандарт языка C. но да, лучше было бы, если бы memcpy при перекрывающихся регионах вызывала exit(1). Тогда бы такие криводелы сразу бы видели свои баги

но да, лучше было бы, если бы memcpy при перекрывающихся регионах вызывала exit(1).

Было бы гораздо лучше если бы при обнаружении перекрывающихся регионов, memcpy сама бы джампила на memmove.

Это поддерживает привычку не читать стандарты.

лучше было бы, если бы memcpy при перекрывающихся регионах вызывала exit(1)

Это C, детка, тут могут и указатель на NULL разыменовать.

Это поддерживает привычку не читать стандарты.

Стандарты читают разработчики. А кто именно из них виноват «user don't care»

В той ситуации с флешем, реально проще было исправить glibc

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

Виноват был адоб и только адоб.

«user don't care» кто именно _виноват_. В этом вся суть. Что не понятного то ?

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

«виноват» — понятие субъективное и не имеет отношения к рабочему процессу. Важно то, какое изменение проще. И именно поэтому придумали всякие стандарты, рефакторинги и прочее: чтобы проще было изменять и писать код. А не для того, чтобы на них фапали как на истину.

Почему надо что-то делать тем, кто и так все сделал правильно, и даже увеличил скорость, непонятно.

Матч по водному поло в Тбилиси.

Тренер кричит:"Гиви, отдай мяч Гоги!
Гиви: "ТрЭнЭр, я сам!
Тренер: Гиви, отдай мяч Гоги!
Гиви: "ТрЭнЭр, я сам!
Тренер:"Гиви, отдай мяч Гоги!
Гиви: "ТрЭнЭр, я гол забил!
Тренер: Ты гол забил, а Гоги утонул!

«виноват» — понятие субъективное и не имеет отношения к рабочему процессу.

В данной ситуации термин «виноват» работает совершенно объективно. Виноват тот, чей код не соответствует стандарту языка, на котором он написан

И что с того, что какому-то быдлу пофигу на то, кто именно виноват?

Мне почему то кажется что ты мало кодишь в команде :))) user не былдо, user это источник дохода

А Гоги следовало сперва научиться плавать

Виноват тот, чей код не соответствует стандарту языка, на котором он написан

Эта фраза не имеет смысла. Обозвать виноватым ты можешь кого угодно, но менять будут тот код, который изменить проще. Даже если он нарушает стандарт. Потому что важен результат, а не стандарт.

user - источник дохода адоба. Вот пускай адоб и чешется, тем более что накосячил именно он

Виноват тот, чей код не соответствует стандарту языка, на котором он написан

Замечательно ! ВИНОВАТ. Дальше что делать предлагаешь ?

И эта история - реальный случай

Эта история близкий к эталону пример быдлячества, так называемого илитизма. Ну как можно доверять хрен знает кому строить дом? Ок, даже не хрен знает кому, по диагонали прочитал профиль компании и даже портфолио, но каким же быдлом надо быть что бы доверить стройку компании не имеющей опыта в данном виде строительства? Каким быдлом надо быть, что бы не иметь своего человека(наёмного профессионала), который будет контролировать основные(или даже все) этапы на ТВОЕЙ же стройке, если ты сам нихрена в этом не разбираешься??? юзир дазнт кер, говоришь?

Потому что важен результат, а не стандарт.

Ну так glibc работает _полностью_корректно_. в ней проблем нет. Что заявлялось, то и реализовано.

А то, что кто-то из адоба хотел использовать нестандартное поведение, так пускай этот кто-то закажет (за деньги) отдельную версию glibc, которая будет работать так, как хочется адобу

Дальше что делать предлагаешь ?

писать адобу о их багах.

А то, что кто-то из адоба хотел использовать нестандартное поведение, так пускай этот кто-то закажет (за деньги) отдельную версию glibc, которая будет работать так, как хочется адобу

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

user - источник дохода адоба. Вот пускай адоб и чешется, тем более что накосячил именно он

Едешь ты на машине, и тут тебе под колеса бросается пешеход. Я правильно понимаю, что ты ему медицинскую помощь не окажешь ? Он же сам бросился, вот пускай сам и чешется. Правда если он умрет, ты сядешь.

Ну как можно доверять хрен знает кому строить дом?

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

Если пешеход целенаправленно бросился, и есть тому подтверждение, то в этом случае ты не виноват.

Но это очень далекая от темы разговора аналогия.

И вообще, законодательство в этой области крайне нелогичное.

То есть ты предлагаешь пользователю дебагнуть код, почитать пару тонн писем в LKML, и потом уже решить кому строчить гневное письмо ? И что потом ? Сидеть и ждать ?

Да. Когда мне надоело хрипение, я прочитал форумы, LKML и обнаружил, что адобу уже написали.

Если пешеход целенаправленно бросился, и есть тому подтверждение, то в этом случае ты не виноват.

Это ты в суде будешь доказывать, возможно уже после того как отсидишь пару лет. А так согласно ПДД - ты обязан как владелец транспортного средства повышенной опасности, именно ты в первую очередь обязан избегать ДТП.

Но это очень далекая от темы разговора аналогия.

Да не, это очень прямая аналогия ситуации когда «user don't care» кто виноват. Один в могиле, один в тюрьме, семьи обоих черт знает где.

Один в могиле, один в тюрьме, семьи обоих черт знает где.

Один не может видос на ютубе посмотреть, другого быдлокодером обозвали. Вот это «аналогия».

А так согласно ПДД

В ПДД этого нет, это в другом месте находится.

И поясни совсем понятно, как наличие еб*тых законов в этой стране соотносится с ситуацией, когда накосячил адоб, а бочку катят на разработчиков glibc?

Тебе видимо откровенно было нечем заняться. :)))

Может быть давай лучше возьмем другой пример ? Вот Моззиловцы взяли на себя идиотское решение, заблокировать JAVA плугин. Что предлагаешь читать и куда писать пользователям в этом случае ?

И поясни совсем понятно, как наличие еб*тых законов в этой стране соотносится с ситуацией, когда накосячил адоб, а бочку катят на разработчиков glibc?

Никак не соотноситься, ибо весь пример направлен на то что бы объяснить что не имеет значение кто виноват. Имеет значение кто быстрее может исправить ситуацию (остановить кровотечение)

Более правильная аналогия: в автосервисе починили тормоз, водила по привычке вдавил педаль в пол — и у*бался лбом в стекло.

А в чем история заключается с плагином?

Имеет значение кто быстрее может исправить ситуацию (остановить кровотечение)

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

Какое дело пользователю какими словами разработчики друг друга отмеряют ?

Может им еще и сексуальными предпочтениями разработчиков интересоваться ?

Я тебе объясняю что ты выбрал неправильную аналогию, сравнивая смерить человека с неработающим флеш-плагином.

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

Ололо! Ок , продолжаем изучать особенности твоего мира где ехал быдло через быдло и забрызгал грязью господина в белом. Так вот, во первых, каждый гражданин имеет право подать в суд на что угодно и на кого угодно, но свою правоту он должен доказать в суде. Во вторых, цемент завод поставил то что у него заказали, у него все накладные и прочие сопутствующие документы имеются + экспертиза бетона из фундамента покажет, что никаких отклонений при его изготовлении не было. Сам догадаешься или подсказать, кого суд обяжет оплатить данные телодвижения, не только судебные издержки, но и экспертизы и прочее сопутствующее?

https://bugzilla.mozilla.org/show_bug.cgi?id=914690

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

Фишка в том, что тут виноватых хрен найдешь, а делать анализы на мед. оборудовании нужно уже сейчас

Ясен пень, что быдла. Но я и говорю, что катить жалобу на завод не имеет смысла. Собственно, заказчик дома этого и не делал. Он, ЕМНИП, потом долго пытался разыскать ту бригаду строителей (дело было в 90-х) и стребовать с них.

Я тебе объясняю что ты выбрал неправильную аналогию, сравнивая смерить человека с неработающим флеш-плагином.

Аналогия абсолютно правильная, прием называется гипербола.

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

Следующий этап, это осознание что данный подход от цены вопроса не зависит. Как правило встречает сопротивление «аля у вас неправильная аналогия». /0

неважно кто виноват - куда важнее что можно сделать

но делать должен тот, кто виноват

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

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

Спор Линус vs Дреппер был не об этом, а именно о том, можно ли ломать конкретное поведение функции в условиях UB.

но делать должен тот, кто виноват

Вот тебе бинт и жгут, перетягивай сам. Что ? Руки сломаны ? Сам виноват - жди когда врачи приедут :)))

Это в идеальном мире должен делать тот кто виноват. В жизни всё зависит от ситуации. Как в армейской поговорке, командир разберется как следует и накажет кого попало.

Нельзя. По историческим причинам. Потому что «user don't care»

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

В жизни всё зависит от ситуации

Вот именно, а не так как ты предлагаешь - делать «лишь бы работало»

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

Не должно быть в стандарте UB. Вот и всё. Нет UB нет спора.

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

Нельзя. По историческим причинам. Потому что «user don't care»

Да пофигу. Если, например, будет реализовано быстрое полностью аппаратное memcpy, рандомно засирающее весь регион при пересекающихся регионах, то не использовать его только из-за пары криворукожопых индусов из адоба - верх глупости.

но делать должен тот, кто виноват

Зависит также от того, какие цели ставит перед собой невиновная сторона.

Линус рассматривал проблему с быдлофлешем как бизнесмен, а не как инженер.

Можно и так. «user don't care» наши с тобой взаиморасчеты

И именно так и было бы, если бы адоб за деньги попросил бы Дреппера сделать специальную версию glibc с тем memcpy, к которому адоб привык

то не использовать его только из-за пары криворукожопых индусов из адоба - верх глупости.

Ну... это опенсурс. Никто не мешает сделать свою libc с шахматами и поэтессами.

Потому что «user don't care»

Точно так же можно сказать «developer don't care».

Вот пускай адоб (или пользователь), если ему требуется, и делает. Или отдельно заказывает у команды glibc.

Точно так же можно сказать «developer don't care».

Можно конечно. Но для Линуса очевидно users важнее чем developers

А являются ли user'ами те, кто сам ничего не вкладывает в мир СПО? Или же это крысы, подбирающие объедки со стола?

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

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

Ну тогда вопрос снимается вообще.

Есть у меня знакомый, достаточно упорный и очень даже логичный.

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

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

На что он совершенно логично замечает, что раньше такой услуги у него не было и он её не заказывал, оператор ему её навязал, он не обязан никуда идти, стоять в очереди и подписывать какую-то бумажку. Его «don't care» как оператор исправит свой собственный косяк. Сами изменили набор услуг - вот сами и разбирайтесь.

Ты мне в данной ситуации напоминаешь сотрудника оператора, который вместо решения косяка внутри оператора сваливает решение на юзера.

Опять мимо. Оператор сам накосячил, сам пусть и исправляет. С memcpy накосячил адоб, а виноват почему-то оказался разработчик glibc.

Где это описано в GPL ?

Если в договоре обслуживания записано, что оператор имеет право подключать сам, а отключение только по письменному заявлению, то сотрудник оператора полностью прав

Там эта тема не затронута

С точки зрения пользователя - накосячили разработчики дистра, где то внутри дистра. Почему вы посылаете его читать LKML и самостоятельно решать проблемы ?

С memcpy накосячил адоб, а виноват почему-то оказался разработчик glibc.

Да «user don't care»? адоб виноват или разработчик glibc, для него они все разработчики. А он user, почему его должны волновать их распри ?

Наверное потому что понятие «свободное» не оперирует категориями крысы, объедки, вкладывал не вкладывал

А он user, почему его должны волновать их распри ?

Он user, а не царь и бог. Если что-то не работает, пускай найдет, что именно не работает и напишет подробный багрепорт тому, кто накосячил.

А являются ли user'ами те, кто сам ничего не вкладывает в мир СПО? Или же это крысы, подбирающие объедки со стола?

Слишком толсто.

Он user, а не царь и бог.

И место его у параши, правильно?

Я дальше описал, где его место и чем ему следует заняться в случае проблем

Чтобы не было как у моей знакомой, у которой принтер не печатал документ, сколько бы раз она не переставляла дрова, и в итоге она со злости чуть не сломала его, а оказалось, что у нее была кривая версия какого-то левого офиса

Почему вы посылаете его читать LKML

Кто «мы»? Юзеру остается только ждать, пока программисты решают что делать, если уж он не может сам сделать элементарный preload. Самым худшим решением было бы откатить изменения в glibc. Лучшим — исправить flash, что и было сделано.

Где в документации дистра написано что user care ?

Это написано в том месте, где говорится, что софт поставляется AS IS, без всяких гарантий. Что-то не нравится - максимально локализуй причину и пиши разработчикам.

Самым худшим решением было бы откатить изменения в glibc.

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

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

Что-то не нравится - максимально локализуй причину и пиши разработчикам.

Домыслы. В которых что ни пользователь так системный программист

Домыслы.

Нет. В багтрекере дебиана даже есть графа Package, куда надо вписать название неисправного пакета, в других дистрах вроде так же

Я дальше описал, где его место и чем ему следует заняться в случае проблем

То что ты написал дальше и есть «место у параши». Только в отличии от твоих умозаключений это не аналогия, а краткое и ёмкое резюме. Так всё таки ПО для человека или человек для ПО?

В таком случае ничего кроме «места у параши» нет, потому что этим следует заняться не только конечному пользователю

Если что-то не работает, пускай найдет, что именно не работает и напишет подробный багрепорт тому, кто накосячил.

https://bugzilla.mozilla.org/show_bug.cgi?id=914690#c49

Oh, that's easy to explain, so I'll do that.

Because my users 1) don't all have an email, 2) don't always read it, 3) can't or won't follow those instructions.

You are used to deal with people familiar and comfortable with IT in general and GUIs in particular. You know your way around computers and can adapt when faced with new situations. My users are not that.

For the purposes of this bug, my users are mostly nurses. Some of them don't even have computers at home, they don't understand IT, they don't WANT to understand IT. Computers are a chore at best. They use them because their job demands it at certain times, but they don't have the reflexes we «IT people» have when confronted to a software problem. A 16x16px red icon means nothing to them, they don't see it, they're not trained to look for it the way we are. And even when I point the solution to them, they'll have forgotten as soon as the issue is resolved. They will not look for it the next time. Because it's IT work, and they're not IT people.

There's no real solution for this problem from the user side. I can't train them on the job, because they're 500 and I'm alone. I can't send them to training sessions, because there's no such thing and even if we found one, it's not really job-related and there's no way we can justify the expense. I can't ask them to self-train, because knowing about computers IS NOT THEIR JOB, and you can't ask 40- or 50-year old people with no affinity to IT to just develop an interest in computers just because it makes your life easier. (Well, that's valid regardless of age, actually.)

The only solution to this problem is to make IT as hidden as possible. The less interaction they have with it the better. Automate as much as possible. Hide everything they don't use, reduce dialog boxes to a minimum. Etc.

That's been my everyday job for the last 13 years. My colleagues in other, nearby hospitals have the exact same issues with their own users, whether they have less (~300) or more (~2000) users, or whether they have an IT team of 1 (like me) or ~10 (for the biggest of my neighbours).

So, yeah. «Look for that icon. Click on it then say 'Enable always' everytime Java updates». Not gonna happen. They don't even understand the concept of a plugin or what Java even DOES.

Now, again, I understand your position from a software engineering POV. I'll even agree that it makes sense.

Unfortunately, it doesn't make sense anymore once Firefox is installed and in the hand of actual, non-IT-oriented users. I'm sorry.

Ага... разобраться... и отрепортить, что бы наткнуться на WONT FIX

they don't WANT to understand IT.

Пускай обращаются к тем, кто понимает IT. А в случае сабжа лучше поставлять готовый «программно-аппаратный комплекс» с той версией FF, в которой есть нужный функционал.

В таком случае ничего кроме «места у параши» нет, потому что этим следует заняться не только конечному пользователю

А ни фига. ПО для человека, а не человек для ПО. Сам догадаешься почему или подсказать?

ПО для человека, а не человек для ПО.

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

М-да. Ты понимаешь разницу между юзером, технишеном и инжинером?

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

Потому что «user don't care»

Точно так же можно сказать «developer don't care».

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

Так можно сказать, только

Нет, не только. Не все работают непосредственно на конечного пользователя, которому нужно «здесь и сейчас».

Нет, не только. Не все работают непосредственно на конечного пользователя, которому нужно «здесь и сейчас».

В конечном итоге - все, вопрос только в длине цепочки. И непосредственные работодатели обычно тоже не будут особо разбираться, кто тут поступил по понятиям, а кто - нет. Сломал - чини.

Сломал - чини.

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

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

Это не техзадание.

Ну… а user don't care.

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

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

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

То что ты описал, конечно, хорошо и правильно, но в общем-то оно называется итальянская забастовка.

Накатываем патч на glibc, ломается флеш. Значит это плохой патч, даже если он проходит тесты.

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

Значит это плохой патч, даже если он проходит тесты.

Нет, это плохой флеш, плюющий на утвержденные стандарты

То что ты описал, конечно, хорошо и правильно, но в общем-то оно называется итальянская забастовка.

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

Накатываем патч на glibc, ломается флеш. Значит это плохой патч, даже если он проходит тесты.

Это значит, что плохой флэш.

Я написал функцию «константа» вот такого вида

double mathconst(char ** e) {
   if (strcasecmp(e,"zero")==0) return 0;
   if (strcasecmp(e,"e")==0) return 2.7182;
   return 3.1416;
}

и задокументировал её так «возвращает значение затребованной константы, аргумент - имя константы, можеьт быть pi, e или zero»

Программистка Адобася Долбакова решила использовать эту функцию для вычисления длины окружности:

double clen(double rad) {
    return 2*mathconst("pie")*rad;
}

Теперь я решил улучшить свою функцию, и переписал её:

double mathconst(char ** e) {
   if (strcasecmp(e,"zero")==0) return 0;
   if (strcasecmp(e,"e")==0) return 2.7182;
   if (strcasecmp(e,"pi")==0) return 3.1416;
   return -1;
}

Так вот - то, что у Адобаси Долбаковой сломалась её программа - проблема Адобаси Долбаковой. Потому, что воспользовалась UB.

Если malloc выделял память с выравнивание на 32 байта, то можно сделать malloc(16) и записать туда 24 байта. А в следующей версии malloc изменят, и он будет выделять память с выравниванием на 8 байт. И кривая программа сломается или начнет крушить данные. Это не проблема автора malloc, это проблема быдлокодера чья программа нарушает правила.

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

double mathconst(char ** e)

Ты тут точно аргумент не напутал?

ну в общем-то да, должно было быть (char * e)

Давно на низкоуровневом не писал.

Так вот - то, что у Адобаси Долбаковой сломалась её программа - проблема Адобаси Долбаковой. Потому, что воспользовалась UB.

Сейчас набегут и начнут писать, что это проблема user'а, а так как Адобася ушла в запой и пальцем не пошевелит для решения, ты должен вернуть старое поведение.

Ну так glibc работает _полностью_корректно_. в ней проблем нет. Что заявлялось, то и реализовано.

Ну а мне, как пользователю, на это чихать. Я знаю, что я обновил жлибц, и у меня сломался флеш. Я знаю, что с предыдущей версией именно жлибц флеш работал. Ergo, этот ваш дреппер своим жлибцом сломал мне флеш.

Вот и весь смысл. А кто там виноват на самом деле, мне посрать. Я всего-то хочу смотреть видео с котейками или бабами обнаженными.

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

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

Когда флеш на линуксе тормозит, глючит или не работает, то это не флеш плохой, а линукс плохой. И вариант, при котором флеш работает, полностью соответствует стандарту. В си использование значения неинициализированной переменной тоже UB, однако gcc услужливо подставляет нули где можно. Уверен, что если это дело пропатчить обратно на UB, много чего отвалится.

Особенно неудивительно слышать такую фразу от Линуса, он во-первых прагматик, а не идеалист, во-вторых он никогда не делает в ядре изменений, ломающих юзерспейс.

В си использование значения неинициализированной переменной тоже UB, однако gcc услужливо подставляет нули где можно.

gcc такого не делает:

~> cat ub.c
#include <stdio.h>

void test1() {
	int a = 10;
	printf("%d\n", a);
}

void test2() {
	int a;
	printf("%d\n", a);
}

int main() {
	test1();
	test2();
}
~> ./ub
10
10

Да, про гцц был не прав, с чего-то решил, что он подставляет. Но тем не менее суть ясна. Если на определённый вариант раскрытия UB много чего начинает быть завязано, то этот вариант раскрытия UB стоит считать стандартом.

я думаю, что постинг на лоре подходит под понятие «вклад в спо»

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

ВНЕЗАПНО: у них нет денег на программистов.

так как Адобася ушла в запой и пальцем не пошевелит

зачем ты финансируешь её запой?

ты должен вернуть старое поведение.

проще послать адобасю в пешее эротическое путешествие.

Вот и весь смысл. А кто там виноват на самом деле, мне посрать. Я всего-то хочу смотреть видео с котейками или бабами обнаженными.

детка, плати деньги мысы, или красной шапке, которая бекпортит старый жлибц. Там всё работает. (только не путай бесплатный стартер или CentOS с Windows & RHEL).

однако gcc услужливо подставляет нули где можно.

gcc такого не делает

а стек не вставляет. А вот в статические и в глобальные — вставляет, и это не UB, а стандарт.

Но тем не менее суть ясна. Если на определённый вариант раскрытия UB много чего начинает быть завязано, то этот вариант раскрытия UB стоит считать стандартом.

тебе пометочку надо: «быдлокодер».

Я написал функцию «константа» вот такого вида

возвращает значение затребованной константы, аргумент - имя константы, можеьт быть pi, e или zero

А вот фиг. Твоя функция возвращает значение затребованной константы e или zero, и значение pi в ином случае. Так что это ошибвка документации, и тут виноват таки ты.

Можешь помечать меня как хочешь, но я не понимаю зачем было лезть в glibc и ломать флеш. Чисто из вредности?

Твоя функция возвращает значение затребованной константы e или zero, и значение pi в ином случае. Так что это ошибвка документации, и тут виноват таки ты.

В документации написано, что для нее множеством допустимых аргументов является {«zero», «e», «pi»}, и для каждого из них она возвращает указаное число. А 3.14159 на «pie» возвращает исключительно конкретная реализация. Но «pie» вообще не входит в множество допустимых аргументов, как отрицательные числа не входят в область допустимых аргументов sqrt, хотя какая-нибудь конкретная реализация что-то конкретное выдаст.

Можешь помечать меня как хочешь, но я не понимаю зачем было лезть в glibc и ломать флеш. Чисто из вредности?

его никто не ломал. Memcpy(3) ВСЕГДА обладала этим «багом». И ВСЕГДА этот баг проявлялся если копировать не в ту сторону. В какую именно — зависит от реализации. Если реализация не менялась посл. 7 лет — ничего не значит. ВНЕЗАПНО(для быдлокодеров) — поменялась.

В документации написано, что для нее множеством допустимых аргументов является {«zero», «e», «pi»}, и для каждого из них она возвращает указаное число.

Именно. Но если мы посмотрим на функцию, мы увидим, что это не так. Никакой проверки на допустимость нет, никакого упоминания аргумента «pi» тоже нет. Документация врет, поэтому пользователь основывался на фактической работе функции.

как отрицательные числа не входят в область допустимых аргументов sqrt, хотя какая-нибудь конкретная реализация что-то конкретное выдаст

http://docs.oracle.com/javase/6/docs/api/java/lang/Math.html#sqrt(double)

Смотри-ка, абсолютно все случаи описаны. Слабо так сделать?

его никто не ломал

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

И что ты думаешь во про такую функцию my_sqrt()? Она ведь для отрицательных чисел тоже что-то пишет

#include <stdio.h>

#define abs(x) ((x)>0?(x):(-(x)))

double my_sqrt(double x)
{
        double res = 1;
        int i = 0;
        while (abs(x - res) > 0.2 && i < 100)
        {
                res = (res + x/res)/2;
                i++;
        }
        return res;
}


int main(void)
{
        printf("sqrt(16) = %lf\n", my_sqrt(16));
        printf("sqrt(-16) = %lf\n", my_sqrt(-16));

        return 0;
}

~

Что сказать-то хотел? УГ и я могу написать. Как это доказывает, что можно делать изменения в недокументированном быдлокоде?

Это не УГ, это грамотная функция поиска квадратного корня положительного числа. В качестве аргумента принимает положительное число типа double.

А вот что она сделает при отрицательном аргумента - чистейшее UB. И никакого «более-менее» корректного поведения тут не сделать.

И никаких технических причин сохранять my_sqrt(-16) = -3.859442 в ходе дальнейших улучшений нет.

Например, если я решил, что нет смысла ограничивать 100 шагами цикла, а можно 1000, то получаю my_sqrt(-16) = -15.842310

Или перепишу условие цикла

while (abs(x/res-res) > 0.2 && i < 100)

Но при этом всякие Адобаси Долбаковы оказываются в пролете

А вот фиг. Твоя функция возвращает значение затребованной константы e или zero, и значение pi в ином случае

Нет. Функция делает в точности то, что написано в документации.

В спецификации сказано - допустимы ТРИ варианта входного аргумента. Для каждого из них функция возвращает определенное значение. Функция реализует эти требования в полном объеме, значит функция соответствует спецификации.

Всё твои предположения о том, что функция возвращает в остальных случаях - домыслы.

Для memcpy() сказано - копирует регион памяти. Исходный и целевой регионы не должны перекрываться. Всё, эту функцию НЕЛЬЗЯ использовать в случае перекрытия регионов. Вне зависимости от реализации. Попытка опираться на UB - это говнобыдлокод. Тот кто опирается на UB - говнобыдлокодер.

Но если мы посмотрим на функцию, мы увидим, что это не так.

А ты не должен «смотреть на функцию». Ты должен смотреть на ДОКУМЕНТАЦИЮ. Потому, что не можешь даже предполагать, что функция сделает при нарушении документации. Потому, что она имеет право на всё что угодно - от игнорировать ошибку и вплоть до трапнуть программу по SIGKILL и отправить систему в poweroff.

Никакой проверки на допустимость нет, никакого упоминания аргумента «pi» тоже нет.

В документации описано. Документации соответствует. Всё.

Документация врет, поэтому пользователь основывался на фактической работе функции.

Документация не врёт. В документации полностью опиcаны допустимые аргументы. Функции это черный ящик с инструкцией. Всё что не описано в инструкции, имеет право измениться в любой момент. Этому вообще-то на первом курсе учат.

Потому, что она имеет право на всё что угодно - от игнорировать ошибку и вплоть до трапнуть программу по SIGKILL и отправить систему в poweroff.

Про защиту от дурака мсье не слышал? UB не должно быть ни при каких обстоятельствах. Точка.

В документации полностью опиcаны допустимые аргументы.

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

Этому вообще-то на первом курсе учат.

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

А вот что она сделает при отрицательном аргумента - чистейшее UB.

Вот именно, поэтому функция и УГ.

И никакого «более-менее» корректного поведения тут не сделать.

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

Про защиту от дурака мсье не слышал? UB не должно быть ни при каких обстоятельствах. Точка.

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

И никуда от этого не деться, такова природа квадратного корня, что в рамках вещественных чисел извлекать корень из отрицательного нельзя

для этого есть особый вид результата (не число) или исключение.

Ну могу я вписать exit(1);

А лучшая (и на самом деле единственная) защита от дурака - не пускать дураков за компьютер.

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

Выдавать UB уже некорректно.

И никуда от этого не деться, такова природа квадратного корня, что в рамках вещественных чисел извлекать корень из отрицательного нельзя

Выдавать результат нельзя != можно выдавать неопределенный результат.

А лучшая (и на самом деле единственная) защита от дурака - не пускать дураков за компьютер.

Верни аттестат в школу, быстро, решительно! Читающим термины буквально не месте в разработке.

Читающим термины буквально не месте в разработке.

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

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

потому что при любом нестандартном юзкейсе все пищит и портит.

Используешь код не в соответствии с документацией - ты ССЗБ. Что же до «пищит и портит», то наиболее адекватный способ реагирования на заведомо неправильные аргументы - как раз попищать и вырубить программу.

Используешь код не в соответствии с документацией - ты ССЗБ.

В идеальном мире, где документация описывает все и компилятор выбрасывает ошибки при нарушении документированного юзкейса — так и есть. А в нашем мире — увы.

наиболее адекватный способ реагирования на заведомо неправильные аргументы - как раз попищать и вырубить программу

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

где документация описывает все

В случае с memcpy так и есть, хотя, конечно, им следовало жирными буквами вписать в стандарт «НЕЛЬЗЯ ПОДСТАВЛЯТЬ ПЕРЕСЕКАЮЩИЕСЯ РЕГИОНЫ»

Они зачем-то написали UB.

Им следовало поставить проверку и выдавать хотя бы -1 (или что там в сях принято для таких случаев). Тогда проблем бы не было ни у кого.

Им следовало поставить проверку

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

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

Если ты весь такой идеальный и пишешь код без ошибок, это не значит, что так делают все. Человеческий фактор всегда был и всегда будет, и это нормально.

Если ты весь такой идеальный и пишешь код без ошибок, это не значит, что так делают все. Человеческий фактор всегда был и всегда будет, и это нормально.

Это не повод лишать все языки программирования их уникальных возможностей.

Я разве что-то говорил по поводу уникальных возможностей?

Давайте еще в архитектуры различных процессоров добавим всевозможные проверки — ведь люди ошибаются.

Я разве что-то говорил по поводу уникальных возможностей?

А разве я что-то говорил о том, что ты что-то говорил о уникальных возможностях?

Если ты весь такой идеальный и пишешь код без ошибок,

Если я вижу, что в источнике и в приемнике стоит один и тот же массив, я использую только memmove

Это не повод лишать все языки программирования их уникальных возможностей.

К чему это было?

Разве какие-то команды процессора выдают UB?

Разве какие-то команды процессора выдают UB

Да, в reserved битах некоторых регистров может быть что угодно. И когда ты ты с этими регистрами имеешь дело, ты не можешь рассчитывать, что там 0. И если ты попробуешь эти биты изменить, может случиться нежданчик.

И когда ты ты с этими регистрами имеешь дело, ты не можешь рассчитывать, что там 0

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

Но то железячники, они привыкши.

Так может и у нежелезячников надо привычку вырабатывать писать по стандартам?

Стандарты тут ни при чем. Просто у железячников везде такой бардак, поэтому они волей-неволей привыкают проверять каждую строчку кода и искать баги месяцами. А другие люди могут обойтись без этого, если кое-кто не будет писать говнокод и фапать на стандарт. Но зачем, ведь можно потратить несколько дней на срачи с пользователями. Написать 3 строки проверки — это не наш метод, мы положим жизнь за стандарт.

Это не повод лишать все языки программирования их уникальных возможностей.

К чему это было?

К тому, что возможность использовать memcpy для копирования пересекающихся областей памяти — по своему уникальна. Далеко идти не надо, Flash Player тому пример. Другой же вопрос, насколько правильно использовать подобный хак в таком популярном софте как Flash Player.

При чем тут язык программирования? Это же функция из библиотеки.

К тому, что возможность использовать memcpy для копирования пересекающихся областей памяти — по своему уникальна.

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

А другие люди могут обойтись без этого, если кое-кто не будет писать говнокод и фапать на стандарт.

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

Разве какие-то команды процессора выдают UB?

Не UB, но скопирует одну область памяти поверх другой, и даже не заикнется:

rep movsb

Как ты считаешь, стоит и тут добавить аварийное завершение или что-нибудь подобное? Ведь люди ошибаются.

Это же функция из библиотеки.

...языка программирования.

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

Ну, фактически ведь получается что он определен, только не в стандарте, а в его реализации. Вот так и используют.

или же неопределен. Как в случае glibc

Библиотека — не особенность ЯП, а просто реализация. Можно ее форкнуть, не меняя сам ЯП.

Библиотека — не особенность ЯП, а просто реализация. Можно ее форкнуть, не меняя сам ЯП.

Это не часть языка, но его особенность — в случае C стандартные библиотечные функции определяются в первую очередь стандартом самого языка, а не «просто реализацией».

https://en.wikipedia.org/wiki/C_standard_library#Standardization:

Over time, user communities of C shared ideas and implementations of what is now called C standard libraries.

Many of these ideas were incorporated eventually into the definition of the standardized C language.

или же неопределен. Как в случае glibc

Всмысле? glibc — это реализация стандарта, и она содержит вполне себе определенный код. Я могу посмотреть как именно в ней реализовано поведение memcpy при копировании перекрывающихся областей и использовать это в свою пользу, этакий хак.

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

Допустимые аргументы - это те, которые задокументированы.

На первом курсе учат делать проверки и обрабатывать исключения

А читать документацию - на втором, но ты до него не доучился?

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

его сделали те, кто должен был его сделать — инженеры из intel. Memcpy(3) изначально переносила данные так, как ЕЙ было удобнее, если это имеет значение КАК переносить, то нужно юзать memmove(3), которая переносит данные ВСЕГДА правильно, даже если они перекрываются. Memcpy(3) так НЕ делает, и ПОТОМУ работает быстрее. Потому-что переносит в том направлении, в каком БЫСТРЕЕ на ЭТОМ процессоре.

Потому нет ничего удивительного в том, что инженеры intel поменяли направление на более быстрое. Это их работа. Они *должны* были это сделать.

А быдлокодеры из адобы *должны* были читать ман: «The memory areas must not overlap. Use memmove(3) if the memory areas do overlap». Какая буква тут непонятна?

ЗЫЖ а Линус... Вообще-то, это не его дело. И его мнение тут не весомее моего или твоего.

А вот что она сделает при отрицательном аргумента - чистейшее UB. И никакого «более-менее» корректного поведения тут не сделать.

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

В конце концов, основная теорема алгебры гласит, что у любого уравнения второй степени ДВА корня.

И никаких технических причин сохранять my_sqrt(-16) = -3.859442 в ходе дальнейших улучшений нет.

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

Функции это черный ящик с инструкцией.

Это правильный подход. Ибо завтра функция может изменится. К примеру, возможно она будет считать ещё и корни отрицательных чисел. Очевидно, что в первых версиях документации это не может быть отражено(ибо никто не умеет предвидеть будущее).

Всё что не описано в инструкции, имеет право измениться в любой момент. Этому вообще-то на первом курсе учат.

А практика говорит, что оно рано или поздно НЕИЗБЕЖНО изменится.

Выдавать UB уже некорректно.

ты уже научился делить на ноль?

В идеальном мире, где документация описывает все и компилятор выбрасывает ошибки при нарушении документированного юзкейса — так и есть. А в нашем мире — увы.

кстати — у меня выбрасывает. И документация описывает всё, кроме UB.

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

всё правильно. Если ты не уверен — убейся ап стену.

В случае с memcpy так и есть, хотя, конечно, им следовало жирными буквами вписать в стандарт «НЕЛЬЗЯ ПОДСТАВЛЯТЬ ПЕРЕСЕКАЮЩИЕСЯ РЕГИОНЫ»

ВПИСАНО ДАВНО УЖЕ. И в Linux Programmer's Manual, и в MSDN.

Это, блжад, АЗЫ!

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

Им следовало поставить проверку и выдавать хотя бы -1 (или что там в сях принято для таких случаев). Тогда проблем бы не было ни у кого.

ты не понимаешь — на том уровне проверка слишком ДОРОГА. Потому-то быдлокодеры и сэкономили на проверке, которая есть в memmove(3). На спичках.

На самом деле, перекрывающиеся области копировать можно точно также, единственный нюанс — если они перекрываются «вниз», надо их «сверху» копировать, что-бы данные сами себя не затирали. Всего-то делов — проверить разницу, и копировать наоборот. Так и делает memmove(3), которая на 3 такта медленнее из-за этого. (точнее, она намного медленнее в случае обратного копирования большой области из-за невозможности кеширования, однако это не играет роли, потому-что memcpy(3) в данном случае всё только портит, и вообще НИКАК не работает).

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

классический флейм здесь — сборщик мусора. Из-за чего, я его в частности и недолюбливаю, ибо тормозит сильно. Причём тормозит ВНЕЗАПНО, в продакшене. А в тестах всё хорошо.

Вот когда GC хочет заткнуть дырку где был мусор, он сдвигает кусок «назад». Или передний кусок «вперёд». Кеш обычно предвыборку делает, т.е. читает «вперёд», а вот GC этого «не знает», точнее «знает», но неточно. Ибо размер кешей и их организация разная на всех процессорах, и невозможно сказать, что будет выгоднее, копировать 30 байтов «вперёд» или 5 байтов «назад». IRL лучше вообще никак и никуда не копировать ИМХО. Это надёжнее и быстрее, как не странно.

Разве какие-то команды процессора выдают UB?

/0

а если серьёзно, таких команд полно.

К тому, что возможность использовать memcpy для копирования пересекающихся областей памяти — по своему уникальна.

ну да. А ещё можно x-- - --x;

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

в моём было написано UB. А что, теперь наука этот вопрос решила?

А, ну тогда понятно. Если это действительно такая фича ради скорости, то ССЗБ те, кто ее использовал.

Наука этот вопрос решает еще на первых двух курсах технического ВУЗа.

Если это действительно такая фича ради скорости

и там и там rep movs. Только memmove сначала проверяет, а потом копирует. А memcpy НЕ проверяет. Потому чуть быстрее.

Обычно в процессорах ВСЕГДА быстрее копировать «вперёд». «Обычно» это НЕ всегда. «Поломка» как раз и связано в том, что быдлокодеры адобы надеялись, что «обычно» == «всегда», и что «лишь-бы работало на моём локалхосте, а на других насрать».

Конец немного предсказуем...

Наука этот вопрос решает еще на первых двух курсах технического ВУЗа.

это что за вуз такой, где на ноль делят? Ты скажи, страна должна знать в лицо своих героев.

на практике часто решения в комплексных числах имеют важный практический смысл.

С самого начала я написал, что ф-я работает на множестве вещественных чисел

и там и там rep movs.

Нет нет. Там довольно сложный код

С самого начала я написал, что ф-я работает на множестве вещественных чисел

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

Ну или пусть корень из модуля считает, ибо для второй степень ответ отличается лишь углом, который для отрицательного аргумента составляет +-pi/4 AFAIK

Нет нет. Там довольно сложный код

я знаю, что сложный. Ибо перенести 1,2,3,4... байта быстрее не rep movs, а как-то по другому. И это сильно зависит от CPU. В итоге там Over9000 маленьких кусочков отдельно для AMD-K8.4534 и 3х байтов, и далее по списку. И ещё это от выравнивания зависит, нечётные байты сдвигаются как-то иначе на некоторых CPU, чем чётные. Впрочем, все эти оптимизации к нашему спору отношения не имеют.

Исходный и целевой регионы не должны перекрываться.

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

Почему то при делении на ноль мы получаем ошибку деления на ноль, а не некое рандомное число по UB, а то тоже можно было бы написать мол.

оператор деления "/", делитель не должен быть равен нулю.

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

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

В стандарте не должно быть UB

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

Те кто так трясутся от потери скорости на паре сравнений, вполне могут реализовать свою memcpy, либо вообще ассемблерную вставку.

В итоге там Over9000 маленьких кусочков отдельно для AMD-K8.4534 и 3х байтов, и далее по списку.

И если добавить к эти Over9000 кусков, которые явно в рунтайме как то перебираются, еще парочку, задача которых определить пересечение и c-jmp-ить на memmove, то мир рухнет ?

Почему то при делении на ноль мы получаем ошибку деления на ноль, а не некое рандомное число

возьми double, и получишь то, что хочешь.

#include <stdio.h>

int main(int argc, char *argv[])
{
	double x = argc - 1;
	double y = x;
	printf("%f/%f=%f\n", x, y, x/y);
	return 0;
}

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

а он и есть определённый — разница размножается по памяти. Т.е. функция memcpy(3) работает как memset(3).

а именно функция отказывалась работать и выдавала ошибку

вот memmove(3) отказывается работать неправильно, но не возвращает ошибку, а работает правильно.

В стандарте не должно быть UB

почему в мире есть UB, в математике есть UB, а в CS его «не должно быть»?

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

деление double/double тоже успешно завершается без ошибок, выдавая результат -nan. Чем ты недоволен? Да, это на моём Atom N270. На твоём CPU оно может дать что-то другое, если твой CPU не стандартный, и не хочет следовать IEEE754. Выкинь свой комп на помойку.

Те кто так трясутся от потери скорости на паре сравнений, вполне могут реализовать свою memcpy

о том и речь.

И если добавить к эти Over9000 кусков, которые явно в рунтайме как то перебираются, еще парочку, задача которых определить пересечение и c-jmp-ить на memmove, то мир рухнет ?

в memmove свои Over9000 кусочков. Которые правильно работают не только когда области НЕ перекрываются.

И если добавить к эти Over9000 кусков, которые явно в рунтайме как то перебираются, еще парочку, задача которых определить пересечение и c-jmp-ить на memmove, то мир рухнет ?

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

Те кто так трясутся от потери скорости на паре сравнений, вполне могут реализовать свою memcpy, либо вообще ассемблерную вставку.

Так вроде она и так на ассемблере и она как раз для тех, кто трясется от потери скорости. Для остальных есть memmove

А являются ли user'ами те, кто сам ничего не вкладывает в мир СПО? Или же это крысы, подбирающие объедки со стола?

Пользователи СПО — крысы, подбирающие объедки со стола. Очень удачная характеристика, записал.

Так вроде она и так на ассемблере

И как она переключает варианты оптимизации между разными процами ?

и она как раз для тех, кто трясется от потери скорости.

Сильно сомневаюсь что потеря тактов на двух сравнениях заставить их трястись еще больше

Для остальных есть memmove

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

выдавая результат -nan. Чем ты недоволен?

memcpy не выдает аналога "-nan" - вместо этого она грозит пальчиком в документации, и предписывает творить UB в реализации.

UB не место в стандарте.

почему в мире есть UB, в математике есть UB, а в CS его «не должно быть»?

Не знаю, есть мнение что КЭП тут бессилен, если тебе это не очевидно.

Компы - вообще то детерминированные творения.

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

Прекрасно - когда представите реальные результаты по данному вопросу ?

Сильно сомневаюсь что потеря тактов на двух сравнениях заставить их трястись еще больше

блжад — в memmove как раз и добавляются эти 2 такта. Если всё правильно, то она работает ровно на одно сравнение дольше. Начиная с iPentium это ВООБЩЕ времени не занимает, т.к. инструкция сравнения работает ВМЕСТЕ с другой инструкцией. А инструкция перехода вперёд НЕ выполняется, т.к. предсказано, что его НЕ будет.

memmove начинает работать заметно медленно тогда, и только тогда, когда области неправильно перекрыты. Но в этом случае memcpy вообще правильно НЕ РАБОТАЕТ.

А так же есть UB

нет никакого UB. Попробуй молотком закрутить шуруп. Это UB?

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

обычное дело, к сожалению. Просто они где-то услышали, что memcpy «быстрая», или вообще не слышали про memmove.

memcpy не выдает аналога "-nan" - вместо этого она грозит пальчиком в документации, и предписывает творить UB в реализации.

дык в документации деление на ноль == UB. А по жизни получается число НЕЧИСЛО. С memcpy тоже получается НЕКОПИРОВАНИЕ, а какая-то хрень непонятная — размножение какой-то последовательности байтов по всей области.

UB не место в стандарте.

твои предложения стандартиризировать деление на ноль?

Не знаю, есть мнение что КЭП тут бессилен, если тебе это не очевидно. Компы - вообще то детерминированные творения.

кто тебе сказал такую глупость?

Пойми, «детерминированые» значит лишь то, что получается каждый раз одно и то же(и то, с допущением одной программы в одноядерном CPU, и без внешнего мира). Да, одна и та же хрень. Например при делении на ноль компьютер имеет полное право ОДИНАКОВО ЗАВИСАТЬ. Разве такое поведение не детерминировано? При этом другой, точно такой же компьютер может удалить все файлы. Это тоже детерминировано. Радует?

нет никакого UB. Попробуй молотком закрутить шуруп. Это UB?

Мастер кривых аналогий в действии. UB есть. Описано прямо в документации - The memory areas should not overlap.

дык в документации деление на ноль == UB.

Я не знаю как там у тебя лично, у меня деление на ноль генерить ошибку <DIVIDE>

твои предложения стандартиризировать деление на ноль?

Моё предложение состоит в том что было бы гараздо лучше если UB в поведении memcpy не было.

Например при делении на ноль компьютер имеет полное право ОДИНАКОВО ЗАВИСАТЬ.

А программист имеет полное право вызывать memcpy с пересекающимися регионами, ни сама memcpy ни стандарт никак не запрещают ему это делать, более того он может это делать не осознанно(изначально регионы не пересекались, а после n патчей от других разработчиков в 10% случаев стали пересекаться), и что ?

блжад — в memmove как раз и добавляются эти 2 такта. Если всё правильно, то она работает ровно на одно сравнение дольше.

И это стоит того что бы трястись над memcpy и кричать что её нельзя трогать ибо она жутко быстрая, не то что memmove ? Самому то не смешно

Ты к примеру уверен что сам код программы, что вызывает memcpy так же написан оптимально и не жрет лишние 10-20 тактов перед вызовом memcpy, сжирая таким образом всё эту мегаоптимизацию ?

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

Мастер кривых аналогий в действии. UB есть. Описано прямо в документации - The memory areas should not overlap.

в инструкции к печке тоже написано: «нельзя сушить кошек в микроволновке». Вычёркиваем?

Я не знаю как там у тебя лично, у меня деление на ноль генерить ошибку <DIVIDE>

потому-что ты в int'ах считал, а я в float'ах. Нельзя?

ну и потому, никто и не говорит о том, что UB определено, оно НЕ ОПРЕДЕЛЕНО. У тебя так, у меня — эдак, а у васи так ваще член отвалится.

Моё предложение состоит в том что было бы гараздо лучше если UB в поведении memcpy не было.

ищи другой глобус, в котором можно делить на ноль. В этом UB.

А программистговнокодер имеет полное право вызывать memcpy с пересекающимися регионами

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

Да, никто не запрещает. Твоя кошка.

Конечно может. И получается закономерно говно. Что мы и наблюдаем.

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

Хороший стандарт не должен содержать UB, как минимум стремиться к этому /0

И это стоит того что бы трястись над memcpy и кричать что её нельзя трогать ибо она жутко быстрая, не то что memmove ? Самому то не смешно

дык я-то и не использую memcpy тогда, когда этого делать нельзя. У меня нет проблем.

Ты к примеру уверен что сам код программы, что вызывает memcpy так же написан оптимально и не жрет лишние 10-20 тактов перед вызовом memcpy, сжирая таким образом всё эту мегаоптимизацию ?

не уверен. Потому, если мне лень думать, я пишу memmove, УМВР, ЧЯДНТ?

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

а я считаю, что она уже написана, и имеется в glibc. А свою писать не нужно, ибо она будет работать ТОЛЬКО на моём локалхосте. А на остальных будет тупить. Потому я юзаю memmove, которая работает ВЕЗДЕ. Когда ребята в intel придумывают какой-то новый CPU, они делают новые memcpy/memmove, которые работают ещё быстрее. А как — я не знаю. И стандарт не знает. И даже сами ребята не знают, ибо ЕЩЁ НЕ ПРИДУМАЛИ.

А дебилы в адобе решили, что могут видеть будущее. Fail.

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

можно сделать микроволновку, которая будет анализировать внутреннее мяуканье. Её не сделали по двум причинам:

1. ты её не купишь, т.к. она будет стоить не 2000р, а 20 000р. А про кошку ты и без этого в курсе, надеюсь не дебил.

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

Потому микроволновка «только грозит пальчиком из мана». Как и memcpy. Причины те же самые.