Glibc удаляет поддержку архитектуры IA64

Заставляя быдлокодера обращать внимание на undefined behavior. Один раз разработчики из adobe напоролись на такую проблему — в следующий раз будут внимательнее читать маны (или что там у них в винде)

Хм... Я думал, он для людей хотел что-то полезное сделать, а он всего лишь мелким пакостником оказался

Сохранение обратной совместимости с быдлокодом — это именно поощрение плохого стиля программирования.

Сохранение обратной совместимости подъездов и улиц с инвалидами — это именно поощрение людей становиться инвалидами.

И опять кривейшие аналогии.

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

Хорошее решение под лозунгом «Долой некрофилию!».

Так что Дреппер — мужик

Кто знает :(

Однажды Линус ныл, что у него какая-то софтина вызывает getconf с огромной частотой и говорил, чтобы Ульрих не парсил каждый раз то ли /proc то ли /sys, а кешировал результат хотя бы на секунду. Ульрих вроде стоял на своём. Но потом внезапно в репозитории появился его, Ульриха, коммит, добавляющий такое кеширование.

Считается, что Itanium почти целиком вытеснен PowerPC

Это кем считается? 0_о

PowerPC вообще хоть где-то кроме мелкософтовского X-box стоит?

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

PowerPC вообще хоть где-то кроме мелкософтовского X-box стоит?

В серверах и мэйнфреймах IBM. И во встроенных системах.

По-моему, как раз проприетарщики так говорят. Ну кто их просил пользоваться недокументированными возможностями. Это всё равно что, как некоторые делают, чистить чайник от накипи кока-колой. А потом, если кислотность кока-колы понизится, возмущаться, почему её испортили.

Какой далеко идущий вывод, однако.

Ты код адобеплеера видел? И я не видел. И программиста того мы не знаем. Может он 10 лет назад опечатался в одном месте от усталости в конце рабочего дня, а может тот код, где был баг, когда-то вообще не предполагал работу с перекрывающимися участками. Кто в этом виноват? Да никто не виноват. Самое главное: всё все эти годы прекрасно работало, и не было никаких причин думать, что оно работает неправильно. Потому что glibc не выдаёт никакой диагностики о наличии UB. А потом оно сломалось.

Если уж свербит найти виновного, то гораздо больше на эту роль подходит не тот неведомый программист, а вполне известный программист, закоммитивший в glibc. Потому что, еще раз повторяю, glibc не имеет диагностики UB, она не сыпала в логи ворнинги «тут UB, исправь код!», и у того программиста не было возможности выявить проблему.

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

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

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

http://www.microsoft.com/en-us/server-cloud/windows-server/2008-r2-itanium.aspx

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

Смешно смотреть как домохозяйки рассуждают о разработке. :)

Itanium RIP.

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

LOL. Еще одна кухарка учит разрабатывать. :)

Ты код адобеплеера видел? И я не видел. И программиста того мы не знаем. Может он 10 лет назад опечатался в одном месте от усталости в конце рабочего дня, а может тот код, где был баг, когда-то вообще не предполагал работу с перекрывающимися участками. Кто в этом виноват? Да никто не виноват.

А что, у adobe нет исходников флешплеера? Есть. А что, им трудно заменить memcpy на memmove? Это тривиальная задача.

есть же кошерная BSDшная реализация libc. _Праффесионалы_ её и выбирут.

//fixed

расскажи как ты syscall'ы будешь делать

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

кроме флеша ещё назовёшь проги которые завязаны на нестандартном поведении memcpy?

Ну и ещё раз скажу что valgrind на такое ругается. Кто свои поделки не прогонят через valgrind тот осёл.

Потому что glibc не выдаёт никакой диагностики о наличии UB

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

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

PowerPC вообще хоть где-то кроме мелкософтовского X-box стоит?

Архитектура применяется дофига где. Даже в приставках PS3, Wii :) Унылый интел - это профлый век. Правильно выпилили.

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

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

uclibc - все наше )

LOL. Еще одна кухарка учит разрабатывать. :)

Рад, что ты верно оцениваешь свои навыки. А теперь живо на кухню, женщина.

Выкинули два года назад же.

Windows Server 2008 поддержка есть, ничего новее не существует.

А что, у adobe нет исходников флешплеера? Есть. А что, им трудно заменить memcpy на memmove? Это тривиальная задача.

А что, не заменили до сих пор? Я без понятия.

А, тогда понятно.

кроме флеша ещё назовёшь проги которые завязаны на нестандартном поведении memcpy?

А ты готов составить исцерпывающий список прог, которые точно не завязаны? Неужели, не готов?

Если уж свербит найти виновного, то гораздо больше на эту роль подходит не тот неведомый программист, а вполне известный программист, закоммитивший в glibc

А вот хрен там. С точки зрения формальной логики, то достопамятное ломание и фикс в glibc/memcpy явллся абсолютно валидным. Потому, что логика функции на всем множестве правильных исходных значений была абсолютно правильной. UB означает «всё что угодно, от 'всё правильно скопировалось' и вплоть до segmentation fault». И это именно задача прикладного программиста - избегать UB если оно явно упомянутое в документации.

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

А ты готов составить исцерпывающий список прог, которые точно не завязаны?

Следуя дальше твоей логике надо вообще libc весь переписывать и вставлять проверки на каждый чих. И почему только libc? Все остальные либы тоже, а то вдруг что-то там навернётся.

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

А может, это сделано намеренно, иначе будет отъедаться много ресурсов?

Доо, несколько cmp и j** — съедают ну просто ОЧЕНЬ МНОГО ресурсов. Каникулы — время невероятных открытий на ЛОРе.

программист должен прочитать документацию по ней, где чёрным по белому написано, что участки не должны пересекаться

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

Доо, несколько cmp и j** — съедают ну просто ОЧЕНЬ МНОГО ресурсов.

Если memcpy вызывается очень часто, до да, может быть заметно.

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

Ну так если не уверен, что участки не будут пересекаться, почему нельзя использовать memmove?

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

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

LOL. Еще одна кухарка учит разрабатывать. :)

Рад, что ты верно оцениваешь свои навыки. А теперь живо на кухню, женщина.

Ухожу-ухожу. А вы продолжайте, я потом почитаю. :)

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

И эти люди называют других «диванными теоретиками» :/

Следуя дальше твоей логике надо вообще libc весь переписывать и вставлять проверки на каждый чих.

Переписывать — это что из области юных пионеров. Вот дописывать — да, кое-где надо. При чем, большая часть дописывания сведётся к проверкам на NULL. Всё остальное — ­редкие случаи типа этого memcpy.

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

Не все, но многие.

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

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

корректный_код_vs_быстрый_код.jpg

Ну так если не уверен, что участки не будут пересекаться, почему нельзя использовать memmove?

Ты безнадежен. Иксренне надеюсь, что ты не программист.

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

И что там такого, что даёт право писать кривой код, лишь бы он работал на компьютере, на котором тестируется? Тем более в нашем случае не допускать кривизну было легко: не уверен, что участки не будут пересекаться — используй memmove. Хуже не будет. И исправить тоже легко, если даже третьи лица в бинарниках, не имея исходников исправили.

Людей которые специально закладывают в свои программы использование недокументированных фич ничем не вылечить. И тех кто их защищает тоже.

Если уж свербит найти виновного, то гораздо больше на эту роль подходит не тот неведомый программист, а вполне известный программист, закоммитивший в glibc

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

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

Скорости ему захотелось.. Линус правильно спросил - где она, эта скорость? И внятного ответа так и не было... Зато всё сделано «правильно»...

корректный_код_vs_быстрый_код.jpg

Ты такой проницательный, ну прямо как Кэп.

Да объясните же мне наконец, что я не так говорю? По-моему, всё очевидно, даже не программисту. Есть memcpy и memmove. Множество задач, выполняемых memcpy, входит в множество задач, выполняемых memmove. Но memcpy имеет определённые требования к входным данным. Не уверен, что можешь выполнить эти ограничения — используй memmove. Где ошибка в моих суждениях?

Людей которые специально закладывают в свои программы использование недокументированных фич ничем не вылечить. И тех кто их защищает тоже.

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

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

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

Чтобы код был портируемым реально, его надо реально тестить, а без этого будешь огребать проблемы там, где даже не ждёшь.

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

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

И эти люди называют других «диванными теоретиками»

Я нипадеццки прусь с Улриха: как пукнет — сразу внеплановая дисциплина Специальной Олимпиады. Талант, млин!