Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
Сообщение от opennews (?), 28-Май-25, 11:25
В утилите sort, поставляемой в составе пакета GNU Coreutils, выявлена уязвимость (CVE-2025-5278), приводящая к обращению к данным вне границы буфера при сортировке с использованием синтаксиса "+POS1[.C1][OPTS]", применяемого для выделения сортируемых ключей в обрабатываемых данных. Проблема вызвана целочисленным переполнением (wraparound) в функции begfield(), позволяющим прочитать содержимое одного байта данных вне буфера. Уязвимость может использоваться для вызова аварийного завершения приложений или организации утечки информации из процесса при передаче атакующим специально оформленных параметров сортировки. Проблема проявляется начиная с версии 7.2 (2009 год) и пока устранена в форме патча... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63320
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
Сообщение от BUMP (?), 28-Май-25, 11:25
чет не воспроизводится: sort +0.18446744073709551615R /tmp/test aa\nbb
Ответить | Правка | Наверх | Cообщить модератору

	2. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от BUMP (?), 28-Май-25, 11:30
	>> contentecho -e "aa\nbb" > poc_input.txt sort +0.18446744073709551615R  /tmp/test bb aa
	Ответить | Правка | Наверх | Cообщить модератору

	4. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от eugener (ok), 28-Май-25, 11:34
	Подтверждаю, не воспроизводится. Бубунта 22.04.
	Ответить | Правка | Наверх | Cообщить модератору

	5. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (5), 28-Май-25, 11:38
	$ nano /tmp/test $ sort +0.18446744073709551615R /tmp/test sort: open failed: +0.18446744073709551615R: No such file or directory $ cat /tmp/test 1 aa\nbb 3 4 Debian 10
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	9. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (5), 28-Май-25, 11:41
	Так тоже не работает: $ cat /tmp/test 1 aa bb 2 3 $ sort +0.18446744073709551615R /tmp/test sort: open failed: +0.18446744073709551615R: No such file or directory
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (12), 28-Май-25, 11:47
	Нас обманули, расходимся.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от openssh_user (ok), 28-Май-25, 11:58
	Debian 12 stable $ sort +0.18446744073709551615R poc_input.txt aa bb Видимо, уже прилетел сам патч. Кстати, не удивлюсь, если уязвимость найдена с помощью бредоИИ
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	66. "пёя▐п╥п╡п╦п╪п╬я│я┌я▄ п╡ GNU sort, п©я─п╦п╡п╬п╢я▐я┴п╟я▐ п╨ п╡я▀я┘п╬п╢я┐ п╥п╟ пЁя─п╟п╫п╦я├я┐ п╠я┐я└п╣я─п╟"	+1 +/–
	Сообщение от mittwerk (-), 28-Май-25, 14:29
	https://security-tracker.debian.org/tracker/CVE-2025-5278
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+5 +/–
	Сообщение от Аноним (36), 28-Май-25, 12:35
	так на скрине оно с санитайзером, а "Уязвимость может использоваться…" уже требует немного больше затрат, чем простой запуск команды
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	99. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (-), 28-Май-25, 17:12
	>чет не воспроизводится: А это сделано специально, чтобы ушлые люди вроде тебя не воспользовались данной уязвимсотью. Новсти об уязвимостях всегда публикуются после того, как их устранят. Обычно правила такие. После обнаружения авторам даётся трёх месячный срок на исправление.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	126. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+3 +/–
	Сообщение от Аноним (126), 28-Май-25, 18:20
	Нет никаких правил. Эмбарго на 90 дней всего лишь рекомендация. Никто не может тебе запретить публиковать в момент обнаружения, кроме собственной морали.
	Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
Сообщение от Аноним (-), 28-Май-25, 12:02
> Проблема вызвана целочисленным переполнением (wraparound) в > функции begfield(), позволяющим прочитать содержимое одного > байта данных вне буфера. Все как обычно 🥱 Опять запутались в подсчете размера строки. Даже комментировать лень. > Проблема проявляется начиная с версии 7.2 (2009 год) Это еще диды или уже смузихлебы? Хотя какая в общем разница, ни те, ни другие нешмогли.
Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+3 +/–
	Сообщение от Аноним (33), 28-Май-25, 12:29
	> Это еще диды или уже смузихлебы? Ни те, не другие. Это третья категория: сишные бракоделы с халатным отношением к работе.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Смузихлеб забывший пароль (?), 28-Май-25, 14:07
	> При этом утилита sort должна быть скомпилирована с включением Address Sanitizer А может, дело и вовсе в пейсателях компиляторов
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (146), 28-Май-25, 22:35
	Пейсатели компиляторов исполнители идти надо напрямую в IEEE и спрашивать там почему до сих пор нет fat pointer?
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 29-Май-25, 00:07
	Разумеется, все проблемы исключительно из-за отсутствия fat pointer. Ни зависимые типы не изобретены, и даже банально запретить разыменновывание нулевого указателя нельзя.
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (65), 28-Май-25, 14:21
	Вот вот. Для любителей хейтить язык: это не в языке дело, потому что язык жает полную свободу прошраммисту - дело в тех, кто овнокодит. Ну, типа, это надо уметь профейлить в простейшей итерации массива с остановкой на нулевом символе.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	69. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+4 +/–
	Сообщение от Аноним (-), 28-Май-25, 14:45
	> Вот вот. Для любителей хейтить язык: это не в языке дело, Язык это инструмент. Его хейтить бесполезно. Хейтить надо тех дундуков, которые в 21 веке используют каменный топор и зубило, вместо перфоратора. Со словами "а если я окажусь на необитаемом острове?!". > потому что язык жает полную свободу прошраммисту - дело в тех, кто овнокодит. Любители ездить по обочине или парковаться на газоне тоже заявляют про полную свободу. И дико верещат, когда на дорогах начинают ставить отбойники или ограждения зеленых насаждений. > Ну, типа, это надо уметь профейлить в простейшей итерации массива с остановкой на нулевом символе. Судя по распространённости подобных ошибок - "умеют-могут") И за последние лет 50 почти ничего в лучшую сторону не поменялось.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–2 +/–
	Сообщение от Аноним (65), 28-Май-25, 16:08
	>Язык это инструмент Сравнение с зубилом некорректное, это скорее электронный микроскоп или генные "ножницы". >Его хейтить бесполезно Однако многие здесь обожают это делать. >Любители ездить по обочине О, а вот и мои любимые аналогии пошли. Для полного бинго нехватает еще тейков про легализацию оружия и прочего бреда.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
	Сообщение от Аноним (-), 28-Май-25, 16:53
	> Сравнение с зубилом некорректное, это скорее электронный микроскоп или генные "ножницы". Электронный микроскоп? Генные ножницы? В этой убогой поделке можно сделать enum Апельсины, второй enum Крокодилы.... А потом успешно их сравнивать, присваивать друг-другу. Все благодаря тому что внутри это инт. > Однако многие здесь обожают это делать. Разве? Ну может на уровне автоваза) Типа: жигули это не машина, а ведро с гайками. > О, а вот и мои любимые аналогии пошли. Ну №№№№ый бред про "язык жает полную свободу прошраммисту" ты первый начал. Так что кушай. > Для полного бинго нехватает еще тейков про легализацию оружия и прочего бреда. Не, мне больше нравится "в глок17 есть сразу 3 предохранителя, потому что его создатели не хотели отстрелить себе ногу. А вот в СИшке...."
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (94), 28-Май-25, 17:08
	> Не, мне больше нравится "в глок17 есть сразу 3 предохранителя, потому что > его создатели не хотели отстрелить себе ногу. А вот в СИшке...." Сравнивать теплое с мягким - это демагогия.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (-), 28-Май-25, 17:11
	> Сравнивать теплое с мягким - это демагогия. Хм... теплое и мягкое... Напоминает описание гов... Тогда вполне можно сравнить с кодом на СИ!
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:41
	>> Сравнивать теплое с мягким - это демагогия. > Хм... теплое и мягкое... > Напоминает описание гов... Такие первые мысли после 2-х прилагательных только демонстрируют вашу озабоченность о упомянутом вами предмете. > Тогда вполне можно сравнить с кодом на СИ! А можно и не сравнить. Что сказать то хотели? Или так, ради словца спустословить?
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:06
	> Для полного бинго нехватает еще тейков про легализацию оружия и прочего бреда. И что же здесь бредового? В свободном обществе оружие (не автоматическое) - это инструмент обороны индивида.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	95. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (-), 28-Май-25, 17:10
	> И что же здесь бредового? В свободном обществе оружие (не автоматическое) - > это инструмент обороны индивида. Но при этом есть ограничения. Например на владение для людей нарушивших закон. Или для стоящих на психиатрическом лечении. Т.е свобода общества не означает что все дозволено и я могу раздавать пушки на право и на лево.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (94), 28-Май-25, 17:36
	>> И что же здесь бредового? В свободном обществе оружие (не автоматическое) - >> это инструмент обороны индивида. > Но при этом есть ограничения. Если рассматривать свободу, как отсутствие инициированного насилия, то ограничения на общество должны повышать свободу каждого индивида. > Например на владение для людей нарушивших закон. С чего бы это? Это вы сейчас в сторону социального рейтинга предлагаете? > Или для стоящих на психиатрическом лечении. Здесь ограничение имеет место быть. Но такое ограничение в обществе повышает свободу индивидов. > Т.е свобода общества не означает что все дозволено и я могу раздавать > пушки на право и на лево. Общество вообще не может быть свободным или несвободным. Это касается только индивида. Про вседозволенность речи и не идет. Определение свободы дал выше.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (119), 28-Май-25, 17:50
	> Если рассматривать свободу, как отсутствие инициированного насилия, то ограничения на > общество должны повышать свободу каждого индивида. Ну так это же хорошо. > С чего бы это? Это вы сейчас в сторону социального рейтинга предлагаете? Нет, оно прям сейчас так работает. РФ: не выдадут лицензию гражданам, имеющим снятую или погашенную судимость за тяжкое или особо тяжкое преступление США: "Как и большинство прав, право Второй поправки не является неограниченным. Это не право хранить и носить любое оружие любым способом и для любой цели... Мнение Суда не следует воспринимать как ставящее под сомнение давние запреты на владение огнестрельным оружием преступниками и психически больными..." > Здесь ограничение имеет место быть. Но такое ограничение в обществе повышает свободу > индивидов. Еще лучше! > Общество вообще не может быть свободным или несвободным. Это касается только индивида. > Про вседозволенность речи и не идет. Определение свободы дал выше. Вот мы и пришли к общему выводу.
	Ответить | Правка | Наверх | Cообщить модератору

	82. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (158), 28-Май-25, 16:29
	>Хейтить надо тех дундуков, которые в 21 веке используют каменный топор и зубило, вместо перфоратора. >Со словами "а если я окажусь на необитаемом острове?!". На необитаемом острове есть дела поважнее, чем ковырятся в дырявой сишке. С учётом того, что лисп появился раньше чем си, и писать на нём проще чем на си, по крайней мере память побить будет сложнее. А дальше, если нужна оптимизация, то уже на лиспе изобрести какой-нибудь типизированный язык. >И за последние лет 50 почти ничего в лучшую сторону не поменялось. Оно и не может поменяться, ибо любые технологии, какие могут помочь избегать таких ошибок, сишниками яросно отрицаются. Даже просто банальный линтер поверх сишного кода, типа того как реализован liquid haskell или psv studio. Поскольку сишникам сразу придётся переписывать весь своё г-код целиком.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	85. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 16:37
	>> Вот вот. Для любителей хейтить язык: это не в языке дело, >Язык это инструмент. Его хейтить бесполезно. Неудобный инструмент, неудобен сам по себе
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	88. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 16:59
	>>Язык это инструмент. Его хейтить бесполезно. > Неудобный инструмент, неудобен сам по себе Удобство это вкусовщина. Вон пользуются же люди вимом. А вот качество, надежность, скорость - это уже вполне численные показатели.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:15
	> А вот качество, надежность, скорость - это уже вполне численные показатели. Нужно смотреть способен ли язык действовать правилам: 1. Решать имеющиеся проблемы лучше, чем предыдущий. 2. Не приносить новые проблемы. 3. Не усложняться, как инструмент.
	Ответить | Правка | Наверх | Cообщить модератору

	124. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (124), 28-Май-25, 18:02
	Это ответ на ваш комментарий и на opennet.ru/openforum/vsluhforumID3/136975.html#98 > Необходимо обсуждать инструмент в рамках его применения. Например "ядра ОС", "низкоуровневые либы, которые используются везде" ? То что существенно влияет на жизнь людей. > 1. Решать имеющиеся проблемы лучше, чем предыдущий. Тут вроде вопросов нет. Опыт тех, кто использует показывает - что такие решает. > 2. Не приносить новые проблемы. Смотря какие. Когда переходили на автомобили - то проблем было куча, начиная от "в какой аптеке купить бензин", до "у нас куча безработных конюхов и перебрасывателей нав0за". Но для прогресса "надо перевозить грузы из А в Б" они были несущественные. Если проблема в "людям лень учить новое" или "у нас нет столько программистов знающих ЯП" - то это не существенные проблемы. Переход будет растянут во времени. > 3. Не усложняться, как инструмент. Но почему? Переход на новый уровень зачастую сопровождается усложнением. Поршневые самолеты -> турбовинт -> рекативная авиация. Усложнение колосальное, но скорости тоже увеличились существенно. То же самое можно сказать и про компьютеры. Лампы -> ТТЛ-микросхемы -> чипы на миллионы транзисторов. Раньше Радио-86РК можно было собрать на коленке из купленных деталей. Сейчас даже перепаять чип - нужны особые инструменты вроде подогреваемого. Можно придумать кучу других примеров именно инструментов, но мне лениво.
	Ответить | Правка | Наверх | Cообщить модератору

	127. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (126), 28-Май-25, 18:25
	И в каких единицах предлагается измерять качество и надёжность?
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	133. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 18:38
	>Удобство это вкусовщина. Вкусовщина - это понятие от гуманитариев, не умещих в систематизацию. Сейчас, суммаризируя огромнейший массив информации, получается выделить ультранормальный сигнал. >Вон пользуются же люди вимом. У вима есть набор вполне объективных показателей, типа работает через cli, возможность использования без мыши, ориентирован на скорость. По этим параметрам его вполне можено объективно сравнивать с тем же helix или любым другим редактором. >А вот качество, надежность, скорость - это уже вполне численные показатели. У вас до сих пор есть вопросы? Отсуствие гигиены в макросах - один из классических примеров плохого качества си. Таких проблем у си очень много, но каждый раз, о них почему-то забывают.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	135. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (135), 28-Май-25, 18:44
	> Вкусовщина - это понятие от гуманитариев, не умещих в систематизацию. Сейчас, суммаризируя огромнейший массив информации, получается выделить ультранормальный сигнал. Т.е винда. На втором месте макось) > У вима есть набор вполне объективных показателей, типа работает через cli, возможность использования без мыши, ориентирован на скорость. Особенно это вяжется с "я вим освоил за два года" и "подвинуть курсор на 2 строки вверх и на 6 слов влево" в сравнении с "клацнул мышкой". ВИМ это отличный пример того, как один параметры ставят во главу. > У вас до сих пор есть вопросы? Отсутствие гигиены в макросах - один из классических примеров плохого качества си. Таких проблем у си очень много, но каждый раз, о них почему-то забывают. Никто не забывает. Плохое качество СИ - это значит что инструмент плохой-устаревший. Об этом вспоминают каждый раз в любой теме про "типичную дырень". Просто аргументы идут зачастую не валидные. Типа "ой, не страшно" или "вас что лично взломали?!"
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 19:11
	>Особенно это вяжется с "я вим освоил за два года" и "подвинуть курсор на 2 строки вверх и на 6 слов влево" в сравнении с "клацнул мышкой". >ВИМ это отличный пример того, как один параметры ставят во главу. Не один, а несколько, но да, вы правы. Обычно все хвалебные статьи, посвящённые виму, эти моменты явно проговаривают. >Никто не забывает. Как это не забывают? Это самое первое, что делает любой сишник/крестовик. Если никто не знает о проблеме, значит проблемы не существует - они всегда дейстуют в этом ключе. Один из них, хотел мне показать, как в крестах всё замечательно, в плане работы со стороками. И скинул ссылку на свой код. Так там обсуждение даже не дошло до удобства управления памятью или чего-то такого. Даже в этой теме, этот человек усиленно делает вид, что реализация xml парсера, не соответствующая спецификациям, ещё и тормозная до невозможности - нормальна. Всё просто, если в каждой новости приводить список сишных проблем, то у любого человека возникнет вопрос, а почему это в 2025 году за си так цепляются руками и ногами. llvm уже давным давно изобретён, уже даже не нужно писать оптимизирующий компилятор самому. Как и gccjit.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:12
	> Неудобный инструмент, неудобен сам по себе Удобство - это чистейший субъективизм. Кому-то удобно сидеть мышкой в иконки тыкать, как он привык со школы это делать на форточках. А по-другому и не пробовал, работая так много лет. Поэтому индивиду удобно. Необходимо обсуждать инструмент в рамках его применения. Если предлагается другой язык или технология, то это должно решать имеющиеся проблемы, не должно усложнять инструмент и не должно приносить новые проблемы.
	Ответить | Правка | К родителю #85 | Наверх | Cообщить модератору

	125. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 18:06
	Windows OS всё усложняет и приносит новые проблемы. И заметь, я о мышке ничего не сказал.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 18:56
	>Удобство - это чистейший субъективизм. Субъективности самой по себе не существует, это бессмыслица. >Кому-то удобно сидеть мышкой в иконки тыкать, как он привык со школы это делать на форточках А вот это уже объективно. Просто берём и замеряем, сколько вещей можно сделать в инструменте при помощи мышки, и сколько нельзя. Замеряем, насколько это вообще применимо к данной области. Vim, запущенный в консоли, объективно не удобен для работы с помощью мышки. M$ Word объективно неудобен для работы с исходным кодом. >А по-другому и не пробовал, работая так много лет. Это тоже объективный факт. Можно сразу сказать, что людям с узким кругозором/без соответствующего образования неудобна работа с клавиатуры. >Необходимо обсуждать инструмент в рамках его применения. Мне до сих пор никто не обосновал необходимость сишного препроцессора, как текстовой замены без гигиены. Никто не обосновал необходимость в тернарном операторе и if как statement. Актуальность в 2025 году нуль-терминированных строк. И так далее. У этого в 2025 году нет никаких причин, кроме как "так делали раньше". И отказаться от всего этого дела в 1995 году было куда проще чем сейчас. Просто по тому, что легаси, оно пускает корни. И чем глубже эти корни, тем труднее это потом выкорчевать. >не должно усложнять инструмент и не должно приносить новые проблемы. Я надеюсь, что еду вы готовите на костре, а помещение освещаете всё лучинами. Ибо что это за непорядок - лампочкам провода нужны. Где вы провода в глухом лесу найдёте? Новые проблемы логически проистекают из изменения свойств предмета. Ну не будет лампочка столь проста в изготовлении как лучина.
	Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

	91. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:03
	> Язык это инструмент. Его хейтить бесполезно. Инструмент тоже есть смысл обсуждать. > Хейтить надо тех дундуков, которые в 21 веке используют каменный топор и зубило, вместо > перфоратора. В каких-то случаях и это может понадобиться. > Любители ездить по обочине или парковаться на газоне тоже заявляют про полную свободу. > И дико верещат, когда на дорогах начинают ставить отбойники или ограждения зеленых > насаждений. Это только показывает, что эти люди не знают, что свобода - это отсутствие инициированного насилия, а не вседозволенность.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

	93. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (-), 28-Май-25, 17:07
	> Инструмент тоже есть смысл обсуждать. К сожалению как только звучит фраза "инструмент безбожно устарел, приводит к куче однотипных ошибок" то начинается какая-то шизофрения про теории заговора, или, что еще хуже, "ну подумаешь ошибка". > В каких-то случаях и это может понадобиться. Вот именно в этих случаях его и надо применять. Назвать "спец.инструмент". Типа медного молотка для работе во взрывоопасной среде. Но для меня главное - чтобы программы были надежными. А не как сейчас.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:17
	> К сожалению как только звучит фраза "инструмент безбожно устарел, приводит к куче > однотипных ошибок" то начинается какая-то шизофрения про теории заговора, или, что > еще хуже, "ну подумаешь ошибка". > Но для меня главное - чтобы программы были надежными. > А не как сейчас. Ответил на это в другой ветке: https://www.opennet.dev/openforum/vsluhforumID3/136975.html#102
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от xPhoenix (ok), 28-Май-25, 15:25
	Других разработчиков на C у меня для вас нет.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	42. Скрыто модератором	+1 +/–
	Сообщение от Аноним (42), 28-Май-25, 13:12
	>Даже комментировать лень. >Зачем-то комментирует.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	55. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Соль земли2 (?), 28-Май-25, 13:42
	не запутались, а забыли заюзать строковую функцию с явным указанием размера буфера
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

17. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+3 +/–
Сообщение от Аноним (-), 28-Май-25, 12:04
Всего-то 16 лет была уязвимость, которая могла использоваться для "организации утечки информации из процесса при передаче атакующим специально оформленных параметров сортировки" ? Ничего страшного! Дело то житейское. Ну тысячи глаз пырились годами в код.. но таки нашли. И пофиксили! Так что "граждане расходитесь, тут нет ничего интересного!")) ps а потом люди спрашивают "зачем бубунтоиды хотят выкинуть coreutils?! они же просто годами работали!" ахаха, работали они, годами)))
Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от anonymous (??), 28-Май-25, 12:06
	Бубунта теперь оплот секретности?
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+3 +/–
	Сообщение от Аноним (-), 28-Май-25, 12:13
	В новости не только про секртность, но и про "вызова аварийного завершения приложений". А убунта.. Ставится на компы из топ500 и на менйреймы ИБМ.. Но так простой и удобный дистрибутив.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (120), 28-Май-25, 17:54
	У ИБМ свой дистр есть теперь.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (126), 28-Май-25, 18:31
	У IBM чего только нет, даже AIX, но ставят они то, что просят клиенты. И клиенты, внезапно, просят иногда и Убунту, и SUSE, и даже иногда какую-то маргинальщину собственного изготовления. А у IBM подход простой: (почти) любой каприз за ваши деньги.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+9 +/–
	Сообщение от IZh. (?), 28-Май-25, 12:10
	А часто в обычых линуксах сочетаются эти условия? 1) привилегированный процесс запускает sort с указанными аргументами, 2) непривилегированный процесс может подсунуть данные привилегированному процессу. Кроме самого факта наличия где-то бага, важна ещё практическая (не)возможность это проэксплуатировать.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	34. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
	Сообщение от ProfessorNavigator (ok), 28-Май-25, 12:34
	Судя по давности бага - за 16 лет ни разу не проявлялось, иначе бы уже нашли. Тут как с торнадо и мусорной свалкой. Вероятность того, что торнадо, пройдя по мусорной свалке, соберёт Боинг 747, не нулевая. Но за всю историю такого не было ещё ни разу. Так и здесь. Ну или ещё можно неуловимого Джо вспомнить. Которого никто не может поймать, потому что он даром никому не сдался. Но вы никого ни в чём не убедите. Поскольку цель публикации таких новостей не обрисовать проблему, а дать повод покричать на тему, которая тут всем уже приелась.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 12:38
	> Поскольку цель публикации таких новостей не обрисовать > проблему, а дать повод покричать на тему, которая тут всем уже приелась. Вы про то, что программисты не умеют программировать? Полностью согласен! Нужно регулярно освещать такие случаи, чтобы каждый программист осознавал свою ответственность перед обществом. Можно даже в районах где они обитают - ну там всякие бизнесс-центры и технопарки - вешать биллборды социальной рекламы "Программист! Помни что твой баг может нанести ущерб народному хозяйству!" или что-то подобное.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от ProfessorNavigator (ok), 28-Май-25, 12:56
	> Вы про то, что программисты не умеют программировать? > Полностью согласен! > Нужно регулярно освещать такие случаи, чтобы каждый программист осознавал свою ответственность > перед обществом. > Можно даже в районах где они обитают - ну там всякие бизнесс-центры > и технопарки - вешать биллборды социальной рекламы "Программист! Помни что твой > баг может нанести ущерб народному хозяйству!" или что-то подобное. Хы, да не уж то кто-то перековался? Не верю)) Идея-то в общем - самое оно.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 13:12
	> Хы, да не уж то кто-то перековался? Не верю)) Идея-то в общем - самое оно. О, наконец-то мы нашли какие-то общие идеи. Но вопрос "а как решить эту проблему"? Для этого можно использовать опыт советской промышленности - рационализаторство. Научная организация труда придуманная Гастевым дает отличные примеры: например "рационализация методов труда" и "улучшение инструментов производства". Например инженер Карташов разработал перемещение шахтного конвейера без его разборки и в разы увеличил добычу угля! Т.е для решения новых вызовов - требуются новые инструменты. Которые обеспечат автоматизацию и лучший результат. Нужны новые языки программирования и новые подходы к обучению специалистов. Но отдельно Гастев отмечает "... обладает тем, что автоматически обеспечивает ему рассчитанную организацию работы, — трудовой культурой. А нашему рабочему её надо ещё прививать. Именно прививать, а не проповедовать! " Т.е критика и публичное освещение таких глупых ошибок, будет мотивировать программистов или проверять результаты своей работы тщательнее, или переходить на инструменты, которые автоматически проверят за него.
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от ProfessorNavigator (ok), 28-Май-25, 13:34
	> Т.е критика и публичное освещение таких глупых ошибок, будет мотивировать программистов > или проверять результаты своей работы тщательнее, или переходить на инструменты, которые > автоматически проверят за него. Так я опять же не против)) Давайте покритикуем. Ошибка была? Уже сомнительно - воспроизвести у народа что-то не особо получается. Но как бы ладно, предположим, что была. За 16 лет хоть где-то проявилась? Нет. Стоит ли об этом говорить? Да, стоит. Собрались на рабочее совещание: "Вася, ты там ляп допустил - поправь". Всё на этом. Этой фигне даже номер CVE присваивать нет смысла. Просто нужно было в рабочем порядке поправить и всё на этом. Никто же код не прячет, история патчей вся доступна. Однако дальше начинается интересное. Сначала кто-то зачем-то вместо того, чтобы прислать патч в рабочем порядке, присвоил этому целый CVE идентификатор. А другой кто-то зачем-то об этом написал новость и опубликовал здесь. Не поленился, потратил время. Зачем? Из альтруизма? Ну-ну)) В мире, где регулярно даже за воздух деньги собрать пытаются - верится с трудом. Да и суть не в этом. В чём собственно новость? В том, что возможно целочисленное переполнение? Так об этом знает любой мало-мальски грамотный программист. И даже тот, кто ошибку допустил, знал. Ошибаются все.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (158), 28-Май-25, 16:30
	>Ошибка была? Уже сомнительно - воспроизвести у народа что-то не особо получается. Но как бы ладно, предположим, что была. За 16 лет хоть где-то проявилась? Нет. Стоит ли об этом говорить? Да, стоит. Собрались на рабочее совещание: "Вася, ты там ляп допустил - поправь". Быстро поднятое не считается упавшим. Правило 5 минут, ой то есть пятидесяти лет - если за пятдесят лет никого не взломали, то это не ошибка.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (158), 28-Май-25, 13:29
	>Тут как с торнадо и мусорной свалкой. Вероятность того, что торнадо, пройдя по мусорной свалке, соберёт Боинг 747, не нулевая Иными словами "не мешайте сишникам г-кодить, они по другому не умеют". >Поскольку цель публикации таких новостей не обрисовать проблему, а дать повод покричать на тему, которая тут всем уже приелась. Проблема давным давно обрисована. Но до тех пор, пока программировать будут люди с музыкальным образованием, любители ходить в суды, данная проблема будет повторяться раз за разом. В 2025 году стыдно иметь такие проблемы, уже давным давно реализована куча языков, где такой проблемы в принципе нет. Хоть ocaml, хоть sml, хоть go, ... >Которого никто не может поймать, потому что он даром никому не сдался Напоминаю, что кроме уязвимостей, существуют ещё и крах процессов. >Но вы никого ни в чём не убедите. Кого убеждать? Человека, который навелосипедил неработающий xml парсер? Вы подписывайтесь под каждым сообщением, о том, что вы хоть и пишите на крестах, но поломанные велосипеды.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	134. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от freehck (ok), 28-Май-25, 18:40
	> "не мешайте сишникам г-кодить, они по другому не умеют". Я как девопс постоянно заставляю работать то, что написали разработчики, и исходя из своего опыта могу сказать только следующее: если вы это считаете сабжевую ошибку гoвнoкoдoм, то вам следует считать гoвнoкoдoм вообще весь софт в мире. Людям свойственно ошибаться, ребята. Не в языке, так в логике. И потому все эти ваши холиворы о том, какой язык лучше -- фигня: какие-то языки лучше в одном, какие-то в другом. Один язык предоставляет больше возможностей, но и несёт больше рисков, в то время как другой -- ну например защищает от рисков, но за счёт увеличенного потребления ресурсов. Всё это в итоге -- трейдофф. Надо уметь балансировать и выбирать правильные инструменты. А гoвнoкoдят в конечном счёте все. Кто-то чаще, кто-то реже, но так или иначе у каждого из нас есть код, который работает, но которым мы не гордимся.
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 19:30
	>Людям свойственно ошибаться, ребята. А ещё, людям свойственно искать способы для предотвращения ошибок. Всяких разных предохранителей, защит от дурака, поручней, касок и так далее. >Не в языке, так в логике. Возмьём двух программистов, один пишет на си, второй на голанге. В то время, как сишник с лёгкостью может допустить утечку памяти или побить память, то голангеру для этого придётся постараться, если он вообще это сможет. >Один язык предоставляет больше возможностей, но и несёт больше рисков, в то время как другой -- ну например защищает от рисков, но за счёт увеличенного потребления ресурсов. Есть такое понятие, как абстракции нулевой цены времени выполнения. Весьма нехитрым образом, можно исключить все ошибки, связанные с нулевым указателем, нужны всего лишь зависимые типы. Да даже без зависимых типов можно слабать решение, запретив разыменновывать сырой указатель. Таких примеров куча. >Всё это в итоге -- трейдофф. Для запрета разыменновывания сырых указателей не нужен дополнительный рантайм, все проверки будут сделаны исключительно во время компиляции. Ещё до появления rust данная идея была в cyclone, в 2001 году. Кто из сишных программистов, осуждающих rust переключился на cyclone? Ats - появился в 2006 году. Кто из сишников переключился на ats? Почему крестовики до сих пор портят память в 2025 году? >А гoвнoкoдят в конечном счёте все. Кто-то чаще, кто-то реже, но так или иначе у каждого из нас есть код, который работает, но которым мы не гордимся. Нет, сишники, как и крестовики вот именно что гордятся. "Посмотрите как изящен strcpy", "просто нужно быть внимательнее", "нужно просто быть внимательным".
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	142. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от freehck (ok), 28-Май-25, 21:10
	> В то время, как сишник с лёгкостью может допустить утечку памяти или побить память, то голангеру для этого придётся постараться, если он вообще это сможет. Да. В этом -- голанг лучше, чем си. С другой стороны, голанг -- язык с рантаймом и сборщиком мусора, и поди его отключи ещё, бинари у него больше, производительность ниже. Это всё равно трейдофф. Ну и вообще странно сравнивать голанг с сями. Языки для разных задач. > Для запрета разыменновывания сырых указателей не нужен дополнительный рантайм, все проверки будут сделаны исключительно во время компиляции. Да, и так например сделано в OCaml, а до этого -- в SML. > Ещё до появления rust данная идея была в cyclone, в 2001 году. Кто из сишных программистов, осуждающих rust переключился на cyclone? На секундочку, SML -- это 1983 год. А ещё в OCaml невозможно словить ошибки типа в рантайме, благодаря решению системы уравнений типов на этапе компиляции. Кто-то из rust-программистов, осуждающих си, переключился на OCaml? Как бы, ну ребят. В Rust ничего нового-то не изобрели, всё ж давно известные вещи. Это просто ещё один язык, ещё один трейдофф. > Почему крестовики до сих пор портят память в 2025 году? Потому что на сях/крестах написано исполинское количество кода, который всё ещё эксплуатируется и потому нуждается в поддержке.
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от ProfessorNavigator (ok), 28-Май-25, 22:41
	> Как бы, ну ребят. В Rust ничего нового-то не изобрели, всё ж давно известные вещи. Это просто ещё один язык, ещё один трейдофф. Да не кормите вы троллей - им платят по количеству комментариев. Им плевать, что вам отвечать - у них методичка перед носом. Большая часть о программировании понятия не имеет. Хотите, чтобы они посмирнее стали - можно в прокуратуру письмо накатать с жалобой на недобросовестную конкуренцию. И не одно. Пускай там с этими на двоих бодаются. А по остальному, в Ржавом ровно одно новшество - встроенный в компилятор статический анализатор. Всё. Да и то, про "новшество" - бо-ольшой вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 23:03
	> Да не кормите вы троллей - им платят по количеству комментариев. А вам за что платят? > Им плевать, что вам отвечать - у них методичка перед носом. Типа "ну нашли ошибку чего бухтеть?" или "надо просто один раз память выделить и один раз очистить" > Хотите, чтобы они посмирнее стали - можно в прокуратуру письмо накатать с жалобой на недобросовестную конкуренцию. А накатывалка не перетрудтится)))? > А по остальному, в Ржавом ровно одно новшество - встроенный в компилятор статический анализатор. Всё. Да и то, про "новшество" - бо-ольшой вопрос. Приведёте пример у кого оно было раньше? Или просто так балаболите, ну чтобы комментов побольше было?
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от freehck (ok), 28-Май-25, 23:08
	> Да не кормите вы троллей - им платят по количеству комментариев. Это конечно многое бы объяснило, но мне трудно представить, что кто-то согласится платить за то, чтобы в рунете поливать одни технологии грязью и пиарить другие. Вот в политике -- это да, это делается, и у нас уже есть масса подтверждений оного. Но в нашей технической сфере?.. Словом, если у вас есть какие-либо подтверждения данного тезиса -- они мне нужны.
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	153. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от ProfessorNavigator (ok), 28-Май-25, 23:31
	> Это конечно многое бы объяснило, но мне трудно представить, что кто-то согласится > платить за то, чтобы в рунете поливать одни технологии грязью и > пиарить другие. Вот в политике -- это да, это делается, и > у нас уже есть масса подтверждений оного. Но в нашей технической > сфере?.. Да вот мне тоже странно. Но тем не менее - факт на лицо. > Словом, если у вас есть какие-либо подтверждения данного тезиса -- они мне > нужны. Смотрите сообщение выше - мне ответили раньше вас, ну и по содержанию поста смотрите. Может, конечно, это лично меня так "любят", но что-то я сильно сомневаюсь. Моя персона не столь значима)) Другие посты здесь полистайте. На лоре - наверняка то же самое происходит. Насчёт хабра - не уверен, проверять нужно. Поэтому и предлагаю в прокуратуру написать. Не знаю, как у вас, а у меня ресурсов особо нет. Прокурорские же могут проверку организовать, если заинтересуются. Запросить ip и все дела. В худшем случае - хотя бы тролль-ферму очередную накроют. Всё поспокойней жить будет. Но тут есть несколько нюансов: по касательной может и opennet зацепить. Как там у римлян было - обращаться в суд, всё равно что дёргать волка за уши? Не помню в общем, но смысл примерно такой. Второй нюанс: если это госзаказ, то можно и проблем огрести. Маловероятно, но кто его знает, чьи тут интересы замешаны. В общем - думайте.
	Ответить | Правка | Наверх | Cообщить модератору

	156. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 00:00
	> Может, конечно, это лично меня так "любят", но что-то я сильно сомневаюсь. Моя персона не столь значима)) Конечно мы вас "любим" профессор! Про вас можно сказать "широко известный в узких кругах". Всегда приятно вечерком почитать смесь теорий заговора с какой-то просветительской деятельностью (с запахом коммунизма в каждый дом). > На лоре - наверняка то же самое происходит. Неа, там есть пара людей, которые любят поджигать пятые точки любbтелям c/c++. Но в отличии от нашего ресурса там народ гораздо подкованее - могут обсуждать что написано в стандарте или сравнивать ассемблерный выхлоп для разных компиляторов. Так что там лучше - аргументов больше. Думаю это из-за того, что там все таки форум, а не древовидные комментарии. > Поэтому и предлагаю в прокуратуру написать. Эх, да вы только предлагаете(( > Не знаю, как у вас, а у меня ресурсов особо нет. Сделайте сбор! На бусти или что там в РФ еще живое. > Прокурорские же могут проверку организовать, если заинтересуются. Запросить ip и все  дела. В худшем случае - хотя бы тролль-ферму очередную накроют. Всё поспокойней жить будет. Кому? Давай уже решать проблему радикально: TOR запретить, вход по паспорту. Новости порочащие славное имя СИ (не китайца) под нож. Хотя про него тоже можно, вдруг партия оценит. За упоминание раста, сразу в бан. Решать будут тройки из неравнодушных граждан. > Второй нюанс: если это госзаказ, то можно и проблем огрести. Маловероятно, но кто его знает, чьи тут интересы замешаны. В общем - думайте. Ваша теория рассыпается как карточный домик от одного вопроса "нафига это в РУнете?" У нас тут вакансий на расте нету, на запад переберутся далеко не все, работать на западные компании... стало немного трудно.
	Ответить | Правка | Наверх | Cообщить модератору

	159. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от freehck (ok), 29-Май-25, 00:09
	> с запахом коммунизма > что там в РФ еще живое > запретить, вход по паспорту > тройки из неравнодушных граждан и что интересно, между определёнными техническими нарративами и нарративами либеральными как будто бы есть корреляция как же чертовски подозрительно всё сходится вот же черти =)
	Ответить | Правка | Наверх | Cообщить модератору

	157. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Прокурорыч (-), 29-Май-25, 00:04
	> Второй нюанс: если это госзаказ, то можно и проблем огрести. Ребята, не стоит вскрывать эту тему. Вы молодые, шутливые, вам все легко. Это не то. Это не Чикатило и даже не архивы спецслужб. Сюда лучше не лезть. Вот оно вам сильно мешает? Ваш любимый язычок обидели?  Сейчас время не то, все нервные, обычных шуточек не понимают, а если вы еще и попытаетесь им палки в колеса своей активной позицией... то можно заработать много денег - тысяч триста в месяц, а может и больше. И никто ничего не заподозрит.
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	161. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 29-Май-25, 00:20
	>>Но в нашей технической сфере?.. >Да вот мне тоже странно. Но тем не менее - факт на лицо. У вас до сих пор нет ни одного факта, только ваши фантазии. И удивительно, но все ваши фантазии исключительно про деньги. Вы ни разу ничего не ответили ни про качество парсера, ни про уязвимости, ни про что-то иное. Как будь-то вы и программировать не умеете, а только деньги считать. >На лоре - наверняка то же самое происходит. Насчёт хабра - не уверен, проверять нужно. И чем же хабр такой особенный?
	Ответить | Правка | К родителю #153 | Наверх | Cообщить модератору

	152. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от freehck (ok), 28-Май-25, 23:28
	> Да не кормите вы троллей - им платят по количеству комментариев Ну всё, блин, спасибо. Я сел на измену. Чем больше я об этом думаю, тем больше начинаю подозревать, что так оно и есть. Очень многое сходится, причём резко.
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	160. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 29-Май-25, 00:11
	>Да не кормите вы троллей - им платят по количеству комментариев. А почему не по количеству символов? Вам что, контракт предлагали? Почему вам везде контракты мерещаться? >Большая часть о программировании понятия не имеет Как там xml парсер поживает? >с жалобой на недобросовестную конкуренцию Конкуренцию с кем? >в Ржавом ровно одно новшество - встроенный в компилятор статический анализатор Разумеется про другие языки из ML семейства вы слышите впервые, когда вам о них уже многократно писали. >Всё. Да и то, про "новшество" - бо-ольшой вопрос. Интересно, когда в вашем проекте появится статический анализатор?
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	154. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Фнон (-), 28-Май-25, 23:34
	> А ещё в OCaml невозможно словить ошибки типа в рантайме, благодаря решению системы уравнений типов на этапе компиляции. > Кто-то из rust-программистов, осуждающих си, переключился на OCaml? Ок, а что с многопоточностью? > Как бы, ну ребят. В Rust ничего нового-то не изобрели, всё ж давно известные вещи. Это просто ещё один язык, ещё один трейдофф. Что-то я не припоминаю ЯП с ownership и системой заимствований. Ну чтоб прям одновременно. У окалма есть очень классная фича, возможность относительно простой верификации. Но практика показала, что это мало кому нужно, к сожалению. Да и сравнивать ЯП со сборкой мусора и без таковой немного странно, вы правильно это заметили говоря про Go. Сyclone интересный, но у него были проблемы - только 32 бита, и отсутствие 64. В 2006 это было уже "слегка" устаревшие возможности. Делали его судя по всему на деньги АТ&T и Корнеллского Университета, деньги закончились - проект закрыли. Sad but true. Авторы циклона пишут, что часть его идей перекочевали в раст. К моменту создания раста, он уже был мертв и скорее всего проще было сделать что-то с нуля, чем разбираться в чужом коде.
	Ответить | Правка | К родителю #142 | Наверх | Cообщить модератору

	155. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от freehck (ok), 29-Май-25, 00:00
	>> А ещё в OCaml невозможно словить ошибки типа в рантайме, благодаря решению системы уравнений типов на этапе компиляции. >> Кто-то из rust-программистов, осуждающих си, переключился на OCaml? > Ок, а что с многопоточностью? Да, многоядерную многопоточность завезли не в 83м, а несколько попозже. ;) >> Как бы, ну ребят. В Rust ничего нового-то не изобрели, всё ж давно известные вещи. Это просто ещё один язык, ещё один трейдофф. > Что-то я не припоминаю ЯП с ownership и системой заимствований. > Ну чтоб прям одновременно. Кстати да, я об этом забыл. Хорошо, контр-аргумент принимаю и признаю, что "ничего" -- это было излишнее обобщение. > сравнивать ЯП со сборкой мусора и без таковой немного странно, вы правильно это заметили говоря про Go Почему я собственно и позволил себе пассаж в виде сравнения Rust с OCaml.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 29-Май-25, 00:26
	>Ну всё, блин, спасибо. Я сел на измену. >Чем больше я об этом думаю, тем больше начинаю подозревать, что так оно и есть. >Очень многое сходится, причём резко. >Да, многоядерную многопоточность завезли не в 83м, а несколько попозже. ;) Надо же, человек знает что-то ещё, ктоме замечательного си. Признавайтесь, за сколько вас купили? >Да и сравнивать ЯП со сборкой мусора и без таковой немного странно, вы правильно это заметили говоря про Go. Довольно странно, что языкам со сборокой мусора внезапно дали зелёный свет. До этого почти всё писали на си, даже там, где объективно можно было взять что угодно, хоть плюсы.
	Ответить | Правка | К родителю #154 | Наверх | Cообщить модератору

	144. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 22:15
	>Кто-то из rust-программистов, осуждающих си, переключился на OCaml? У окамла и раста несколько разные ниши. У си, ats, cyclone, rust - ниша одна и та же. >В Rust ничего нового-то не изобрели, всё ж давно известные вещи. Достижение раста - популяризация линейных типов, хотя он их и не изобрёл. До этого, других популярных языков с линейными типами не было. >Потому что на сях/крестах написано исполинское количество кода, который всё ещё эксплуатируется и потому нуждается в поддержке. И как это мешает? Почему не сделать что-то вроде liquid haskell или typescript, когда изменения внедряются постепенно? Более того, возможно было бы сделать так, что один исходник на си проверялся бы разными линтерами, и линтеры могли бы конкурировать между собой.
	Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

	67. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от User (??), 28-Май-25, 14:36
	Да напиши уже "И таа-аа-аак сойдет! Кому надо - тот пусть и поправит" и Ъ будет.
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	129. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (126), 28-Май-25, 18:32
	#1 достаточно часто, чтобы озаботиться фиксом. #2 — постоянно, на этом гвозде вся «философия» юникса держится.
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	21. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (21), 28-Май-25, 12:10
	Ага, утечка одного байта. Угадай мелодию с одной ноты! Всё правильно: Но таки нашли и пофиксили!
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	51. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (51), 28-Май-25, 13:37
	Коллеги выше попробовали и сказали, что не воспроизводится. Но "Остапа понесло". Позыв не остановить до полного опорожнения кишечника.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	56. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (-), 28-Май-25, 13:44
	> Коллеги выше попробовали и сказали, что не воспроизводится. Конечно мы верим "коллегам-анонимам", а не людям которые исправляют https://lists.gnu.org/archive/html/bug-coreutils/2025-05/msg... Indeed. I introduced this in coreutils 7.2 Типичное УМВР в среде лапчатых. > Но "Остапа понесло". Позыв не остановить до полного опорожнения кишечника. Это печально. Но когда ты закончишь опоржнение, можешь попробовать написать что-то действительно умное.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (65), 28-Май-25, 16:20
	Да, работали. И работают. А 99% уязвимостей, обсуждаемых здесь, обычных пользователей не коснутся. Кому нужды 4% составляющие десктоп линукс? Ембедовка - часто изолированные машины с одним приложением. Никто не пользуется там ничем другим, кроме этого приложения. Серверы - отдельная тема. В конторах обычно вбухивают бабки в безопасность, а не ставят дефолтный дистр. Так что все эти новости только ради того чтобы очередным "исследователям" попилить грантики.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	80. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (-), 28-Май-25, 16:27
	> Серверы - отдельная тема. В конторах обычно вбухивают бабки в безопасность, а > не ставят дефолтный дистр. И? Покажи мне дистр, где используется не гнутый крап? Вот убунта решилась в неЛТС версии сделать и все. > Так что все эти новости только ради того чтобы очередным "исследователям" попилить > грантики. Ну да, а лучше бы потратили эти грантики на улучшение мозговой дейтельности сишников?
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:22
	> ps а потом люди спрашивают "зачем бубунтоиды хотят выкинуть coreutils?! > они же просто годами работали!" > ахаха, работали они, годами))) Вы уверены, что это относится именно к той причине, на которую намекаете? Если это так, то им следует начать с удаления sudo и разного другого, потому что использовать повышение прав обычным пользователем - это уже небезопасно. Для операций по администрированию необходимо использовать чистую консоль и отдельного пользователя или использовать root.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	112. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (112), 28-Май-25, 17:31
	> Вы уверены, что это относится именно к той причине, на которую намекаете? > Если это так, то им следует начать с удаления sudo и Зачем удалять, если можно заменить? opennet.ru/opennews/art.shtml?num=63197 > Для операций по администрированию необходимо использовать чистую консоль > и отдельного пользователя или использовать root. Простите, но таких прдликов практически не осталось.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (94), 28-Май-25, 17:47
	>> Вы уверены, что это относится именно к той причине, на которую намекаете? >> Если это так, то им следует начать с удаления sudo и > Зачем удалять, если можно заменить? > opennet.ru/opennews/art.shtml?num=63197 Если для вас уместно использовать такое поделие, то нам с вами тему безопасности точно обсуждать смысла нет. А тему удобства обсуждать желания нет, ибо уже тошнит от вредных привычек людей, называемые удобством. >> Для операций по администрированию необходимо использовать чистую консоль >> и отдельного пользователя или использовать root. > Простите, но таких прдликов практически не осталось. Сейчас много кого не осталось среди потребителей капитализма.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 19:49
	>А тему удобства обсуждать желания нет, ибо уже тошнит от вредных привычек людей, называемые удобством. Только настоящий сишник знает, что экономия байтов на длину строки в виде \0 - это удобство.
	Ответить | Правка | Наверх | Cообщить модератору

	148. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 22:59
	> Только настоящий сишник знает, что экономия байтов на длину строки в виде \0 - это удобство. Не только! Нул-терминатор так же говорит о единстве всех сишников (и двже отколовшейся сейкты плюсовиков). И о том, что должен быть один язык, один компилятор, один .... \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
	Ответить | Правка | Наверх | Cообщить модератору

26. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
Сообщение от Аноним (26), 28-Май-25, 12:24
Не устаю повторять: виноваты ненастоящие сишники. Настоящие сишники такого бы в принципе не допустили. Удаляю /usr/bin/sort у себя: он писался людьми, прикидывающимися сишниками.
Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от жявамэн (ok), 28-Май-25, 12:25
	ты не настоящий линуксоид у них он /bin/sort
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–2 +/–
	Сообщение от Аноним (26), 28-Май-25, 12:29
	В нормальных дистрах /bin -- это симлинк на /usr/bin. В ветхозаветных дистрах /bin отделен от /usr/bin по ветхозаветным причинам, которые потеряли актуальность уже лет 50 как.
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (21), 28-Май-25, 13:49
	Нормальных?
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (51), 28-Май-25, 13:38
	Это не тот модуль, который основоположник из Миникса как бы не брал?
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

35. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+4 +/–
Сообщение от Ю.Т. (?), 28-Май-25, 12:35
Прогрев для "отмены" свободных решений и замены на контролируемые.
Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
	Сообщение от Аноним (130), 28-Май-25, 18:33
	> Прогрев для "отмены" свободных решений и замены на контролируемые. Сишочные диды-стратеги еще с 2009 года планировали эту диверсию!
	Ответить | Правка | Наверх | Cообщить модератору

37. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
Сообщение от PnD (??), 28-Май-25, 12:37
Вот вроде https://lists.gnu.org/archive/html/bug-coreutils/2025-05/msg... выглядит правдоподобно. Но… - Под RH/SUSE-клонами данная опция тупо не собирается. Нет опции — нет проблемы. - Под debian — собирается, хотя и не внесена в man. Но, ломаться не хочет. Полагаю что "мешают" этому некие нюансы компиляции. Короче, проэксплуатировать такое в "дикой природе" не то чтобы совсем невозможно. Но это надо строить ну ооооочень длинную многоходовку. * При этом, лять, любой "сканер CVE" будет на всё это возбуждаться. И рассказывать что без наисвежайшего патча у вас тут ре́ше́то́.
Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 12:45
	> Короче, проэксплуатировать такое в "дикой природе" не то чтобы совсем невозможно. Но > это надо строить ну ооооочень длинную многоходовку. Типа как провернули с ХЗ? Или как ломали кернел.орг? Там бекдор 2 года был. То что оно маловероятно, не значит что нет точки применения. Вполне возможно это рассчитано на всякую госуху, которая любит древние дистрибутивы.
	Ответить | Правка | Наверх | Cообщить модератору

44. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
Сообщение от xsignal (ok), 28-Май-25, 13:18
Не воспроизводится, фейковая уязвимость.
Ответить | Правка | Наверх | Cообщить модератору

48. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+4 +/–
Сообщение от 12yoexpert (ok), 28-Май-25, 13:32
> Проблему можно воспроизвести попытавшись отсортировать файл, содержащий строку "aa\nbb" командой "./sort +0.18446744073709551615R poc_input.txt". при полной луне, с 30 апреля на первое мая, в Вальпургиеву ночь, когда белая курица станет чёрной и снесёт яйцо
Ответить | Правка | Наверх | Cообщить модератору

	54. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (51), 28-Май-25, 13:41
	> снесёт яйцо Некоторые выше уже снесли.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (21), 28-Май-25, 13:54
	Возможно, что в ночь Ивана Купалы. Уже скоро, надо будет попробовать.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

70. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
Сообщение от ИмяХ (ok), 28-Май-25, 14:48
Если закрыли старый бэкдор, успешно проработавший десятки лет, значит написали новый
Ответить | Правка | Наверх | Cообщить модератору

	73. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 28-Май-25, 14:57
	> Если закрыли старый бэкдор, успешно проработавший десятки лет, значит написали новый Но доказать это не получится, тк "ну подумаешь человек ошибся, с кем не бывает!". Вообще было бы интересно провести исследование "кто писал код в котором нашли CVE и где он работает сейчас". Но мне лень))
	Ответить | Правка | Наверх | Cообщить модератору

78. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
Сообщение от Кошкажена (?), 28-Май-25, 16:10
Забавно как пытаются доказать, что нужно coreutils заменить на раст.
Ответить | Правка | Наверх | Cообщить модератору

	81. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–3 +/–
	Сообщение от Аноним (-), 28-Май-25, 16:29
	> Забавно как пытаются доказать, что нужно coreutils заменить на раст. Никто ничего не пытается. Мы просто смеемся над очередной классической сишной дырой от необучаемых дидов™. А раст приплетаете вы, причем уже не в первый раз. Может вы латентный растаман? Это бы многое объснило))
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+6 +/–
	Сообщение от Кошкажена (?), 28-Май-25, 17:13
	>> Забавно как пытаются доказать, что нужно coreutils заменить на раст. > Никто ничего не пытается. > Мы просто смеемся над очередной классической сишной дырой от необучаемых дидов™. У "дидов" хотя бы есть работающий код. За 10 лет с момента стабильного релиза (и 14 лет с момента начала) растоманы так и не осилили повторить их успех. В чем проблема?
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–5 +/–
	Сообщение от Аноним (-), 28-Май-25, 17:20
	> У "дидов" хотя бы есть работающий код. Работающт глючный дырявый овнокод. Так будет честнее. > За 10 лет с момента  стабильного релиза (и 14 лет с момента начала) растоманы так и > не осилили повторить их успех. В чем проблема? Проблема в "глючный дырявый овнокоде" разумеется. Типа до создания раста он был менее дырявый? Растаманы должны дидам сопли подтирать? Как будто про убогость сишки не писали когда пришел с++ (а это было задолго до раста)?
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
	Сообщение от Кошкажена (?), 28-Май-25, 17:28
	>> У "дидов" хотя бы есть работающий код. > Работающт глючный дырявый овнокод. Так будет честнее. Откажись же, будь верен своим словам. Только тогда бы ты тут не писал.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–2 +/–
	Сообщение от Аноним (112), 28-Май-25, 17:30
	> Откажись же, будь верен своим словам. > Только тогда бы ты тут не писал. Так я верен своим словам - переписываю их код на раст и всецело поддерживают остальных кто это делает. А те, кто об этом не знаю, им я сообщаю насколько плохой старый код :)
	Ответить | Правка | Наверх | Cообщить модератору

	121. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Кошкажена (?), 28-Май-25, 17:55
	>> Откажись же, будь верен своим словам. >> Только тогда бы ты тут не писал. > Так я верен своим словам - переписываю их код на раст По факту ты пользуешься существующим кодом на си и ругаешь его. Если бы ты не пользовался, что ты бы не смог тут написать, как и попросту не смог бы запустить свою ОС.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–2 +/–
	Сообщение от Аноним (119), 28-Май-25, 17:59
	> По факту ты пользуешься существующим кодом на си и ругаешь его. Именно так! Как раз потому что я пользуюсь я имею право критиковать и предлагать улучить. > Если бы ты не пользовался, что ты бы не смог тут написать, > как и попросту не смог бы запустить свою ОС. Вообще я комментирую с redox, но через сишный браузер. Для опенка его на удивление достаточно.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (158), 28-Май-25, 19:46
	>У "дидов" хотя бы есть работающий код. Почему вы называете бажный код работающим? >За 10 лет с момента стабильного релиза (и 14 лет с момента начала) Кто мешал дедам за 10 лет предложить абсолютно любую альтернативу расту? Времени с cyclone (2001) и ats(2006) прошло много, можно было уже что-то и сделать. >так и не осилили повторить их успех. Сишные деды даже свой собственный успех повторить не могут, ибо куча новых проектов начинается, внезапно, на том же голанге. Вот интересно если в докере сборщик мусора не мешает, то почему он должен мешать в том же sudo или sort-е? Это уже не говоря про то, что даже языки не предлагающие ничего революционного, вроде того же zig, тоже откусывают долю от сишного кода.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	165. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 01:45
	>>У "дидов" хотя бы есть работающий код. > Почему вы называете бажный код работающим? Потому что в любом нетривиальном коде есть баги. Странно это объяснять. >>За 10 лет с момента стабильного релиза (и 14 лет с момента начала) > Кто мешал дедам за 10 лет предложить абсолютно любую альтернативу расту? Времени > с cyclone (2001) и ats(2006) прошло много, можно было уже что-то > и сделать. Они знают Си, зачем им альтернатива. Это дело молодых, а они могут только переписывать (и то с трудом, оказывается сложна) и ругать "дидов" на всём готовом. >>так и не осилили повторить их успех. > Сишные деды даже свой собственный успех повторить не могут, ибо куча новых > проектов начинается, внезапно, на том же голанге. Понимаешь абсурдность твоих суждений? "Диды" на голанге уже не пишут, они на заслуженной пенсии.
	Ответить | Правка | Наверх | Cообщить модератору

	175. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 11:50
	> Потому что в любом нетривиальном коде есть баги. Странно это объяснять. А баги в тривиальном коде? Ну типа "не шмогли сделать шплит строки"? > Они знают Си Они знают только сишку и не хотят вообще ничего нового учить. > зачем им альтернатива. Чтобы не делать таких глупых ошибок. > Это дело молодых, а они могут только переписывать (и то с трудом, оказывается сложна) и ругать "дидов" на всём готовом. Конечно сложно. Если код это лапша, без комментариев и с всякими гениальными хаками. Но никто не говорил, что разгребание овен будет легко. И про это "всё готовое" мы почти каждую неделю читаем "нашли ошибку в ..." > Понимаешь абсурдность твоих суждений? "Диды" на голанге уже не пишут, они на заслуженной пенсии. На какой пенсии? Вон Теодор "вы не заставите меня изучить раст" Тцо вполне работает в ядре с 91 года. Даже ставил палки в колеса внедрению раст кода. Интересно будет ли он возбухать сейчас, после того как одного вахтера уже убрали. ps диды это не только возраст, но и мировозрение
	Ответить | Правка | Наверх | Cообщить модератору

	177. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 12:31
	>> Потому что в любом нетривиальном коде есть баги. Странно это объяснять. > А баги в тривиальном коде? > Ну типа "не шмогли сделать шплит строки"? Строки тривиальны? Возможно, если ты не лазил внутрь. >> Они знают Си > Они знают только сишку и не хотят вообще ничего нового учить. И что в этом плохого? Растовщики, такие же. >> Это дело молодых, а они могут только переписывать (и то с трудом, оказывается сложна) и ругать "дидов" на всём готовом. > Конечно сложно. Если код это лапша, без комментариев и с всякими гениальными > хаками. > Но никто не говорил, что разгребание овен будет легко. Не вижу смысла отвечать на этот наброс. А лапшу на расте вижу сильно чаще.
	Ответить | Правка | Наверх | Cообщить модератору

	181. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 12:41
	> Строки тривиальны? Возможно, если ты не лазил внутрь. К сожалению влазил (╥﹏╥) Возможно если взять нормальный инструмент, а не прдолиться с нуль терминаторами ради фикса экономии байта.... Нет!, это не наш путь! Мы добавим в std какие-то огрызки и функции которые писали аутисты, а потом будем героически велосипедить в каждом проекте заново. И наступать на одни и те же грабли. > И что в этом плохого? Растовщики, такие же. Чтобы переписать на раст... нужно внезапно знать си. Так что многие переписывальщики как раз сишные программисты. Которые просто запарились исправлять классические ошибки. Типа как создатели TOR-Arti.
	Ответить | Правка | Наверх | Cообщить модератору

	184. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 29-Май-25, 13:37
	>Строки тривиальны? Возможно, если ты не лазил внутрь. В си нет строк, даже той эпохи, когда они были тривиальными, с простыми однобайтными кодировками. Что сложного в однобайтных строках - вопрос открытый. >Понимаешь абсурдность твоих суждений? "Диды" на голанге уже не пишут, они на заслуженной пенсии. На какой пенсии, вы о чём? Был короткий период, когда си доминировал, победив всякие паскали. Что дальше? А дальше расцвет питонов и жаб. Кресты тоже стремительно вытеснялись везде, где только можно. В том же самом андроиде почему-то использовалась жаба, хотя казалась бы, мобильным устройствам нужна автономность.
	Ответить | Правка | К родителю #177 | Наверх | Cообщить модератору

	185. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 14:23
	>>Строки тривиальны? Возможно, если ты не лазил внутрь. > В си нет строк, даже той эпохи, когда они были тривиальными, с > простыми однобайтными кодировками. Что сложного в однобайтных строках - вопрос открытый. Напиши структуру строки, кто мешает? Если так рассуждать, то строк нигде нет, есть просто последовательность байт. >>Понимаешь абсурдность твоих суждений? "Диды" на голанге уже не пишут, они на заслуженной пенсии. > На какой пенсии, вы о чём? Был короткий период, когда си доминировал, > победив всякие паскали. Что дальше? А дальше расцвет питонов и жаб. > Кресты тоже стремительно вытеснялись везде, где только можно. В том же > самом андроиде почему-то использовалась жаба, хотя казалась бы, мобильным устройствам > нужна автономность. Статистику по языкам в андроиде приведешь сам?
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 11:51
	> Вот интересно если в докере сборщик мусора не мешает, то почему он должен мешать в том же sudo или sort-е? В sudo или sort сборщик мусора вероятно даже будет бонусом. Можно обойтись без сборки мусора, при этом пользуясь всеми перками выделения памяти посредством увеличения указателя, не возясь с более сложными структурами кучи. Другое дело, что вероятно это не повлияет ощутимо на время выполнения, потому что дёргать mmap для получения блока памяти под кучу всё равно придётся. С третьей же стороны, можно было бы болт забить на избегание выделений и программу писать иначе, исходя из того, что много мелких выделений не дольше одного большого, упростив таким образом логику (и снизив число багов) а может и получив какое-то увеличение производительности. Мне в этом смысле больше нравятся новые шеллы, которые вещи типа sort реализуют как built-in команды. Вот тут реально, можно избавиться от fork'ов, и если несколько билтинов чейняться, то нет нужды проталкивать данные через ядро. А потенциально при этом можно ещё и более высокоуровневые оптимизации проделывать, собирая пайплайн, типа как ffmpeg с чейнами фильтров делает.
	Ответить | Правка | К родителю #139 | Наверх | Cообщить модератору

	84. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 28-Май-25, 16:32
	Лично я хотел бы, чтобы заменили на что-то со сборзиком мусора. Очень интересно посмотреть, заметит ли это хоть кто-нибудь. А почему вы про раст говорите - растоман разве?
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	86. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+4 +/–
	Сообщение от xsignal (ok), 28-Май-25, 16:46
	Корпорасты хотят рустифицировать всё открытое ПО и взять под свой контроль.
	Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

	90. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (-), 28-Май-25, 17:01
	> Корпорасты хотят рустифицировать всё открытое ПО и взять под свой контроль. Странно, весна уже давно закончилась, а сезонное обострение у шизов - нет... Может оно уже перманентное? Это бы объяснило, почему он так "качественно" код пишут.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+2 +/–
	Сообщение от Кошкажена (?), 28-Май-25, 17:11
	> Корпорасты хотят рустифицировать всё открытое ПО и взять под свой контроль. Возможно. А как объяснить уже взятые под контроль корпорастами gcc и llvm?
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	113. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (65), 28-Май-25, 17:32
	Для компиляции этими тулзами не нужен доступ к крейтам. Кто будет контролировать крейты, будет контролировать все  по.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+1 +/–
	Сообщение от Аноним (-), 28-Май-25, 20:51
	> А как объяснить уже взятые под контроль корпорастами gcc и llvm? А разве это не очевидно? Чтобы писать оптимизирующий компилятор для разных платформ, нужны 1) знания и умения 2) оплата труды, чтобы работа была более-менее размеренная и предсказуемая. Первого нет у васянов-какиров. Второго нет у сообщества, потому что... а оно просто принципиально не хочет платит. Зато у корпов есть деньги и они могут нанять нужных людей.
	Ответить | Правка | К родителю #97 | Наверх | Cообщить модератору

	143. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 28-Май-25, 22:03
	>> А как объяснить уже взятые под контроль корпорастами gcc и llvm? > А разве это не очевидно? > Чтобы писать оптимизирующий компилятор для разных платформ, нужны > 1) знания и умения > 2) оплата труды, чтобы работа была более-менее размеренная и предсказуемая. > Первого нет у васянов-какиров. > Второго нет у сообщества, потому что... а оно просто принципиально не хочет > платит. Пример, с luajit или qbs говорит, что опыт есть и без корпов. Но корпы заинтересованы, конечно.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 28-Май-25, 22:21
	>или qbs Опечатка, qbe
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (151), 28-Май-25, 23:19
	> Пример, с luajit или qbs говорит, что опыт есть и без корпов. Но корпы заинтересованы, конечно. Шутите? Вы серьезно сравниваете сложность gcc с luajit или qbe? Во-вторых - вы просто подтверждаете мой тезис. Загляните в luajit.org/sponsors.html Cisco Systems, CloudFlare, QUALCOMM, Google, MIPS Technologies, Athena Capital Research, Gehtsoft, Neomantra, Wave Computing, OpenResty и еще куча Anon. *corporate* sponsor. И без них у вас не было бы ни x64 port, ни ARM port, ни MIPS port, ни всего остального важного и нужного. При этом "main LuaJIT author (Mike Pall) is working on unrelated projects" и даже деньги брать не хочет. Ну сорян, нужная вам фича будет сделана... когда-то потом. Но это не точно)) Как вы думаете, кому нужно такая предсказуемость? Ну а QBE вообще выглядит как наколенная поделка "по-приколу". Если расту (а по факту LLVM) ставят в минусы кол-во поддерживаемых платформ... то что можно сказать про QBE с их "amd64 (linux and osx), arm64, and riscv64" и всё? Серьезных пользователей у него нет - пара сишный компиляторов с протухшими стандартами и два языка - Hare и Antimony. Как бы все. Отличный пример того, что происходит когда нет денег и/или времени))
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	163. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 01:19
	>> Пример, с luajit или qbs говорит, что опыт есть и без корпов. Но корпы заинтересованы, конечно. > Шутите? Вы серьезно сравниваете сложность gcc с luajit или qbe? А почему не сравнить qbe с llvm? Дрю ДеВолт сравнивает https://harelang.org/documentation/faq.html#why-qbe-instead-... > Во-вторых - вы просто подтверждаете мой тезис. Загляните в luajit.org/sponsors.html > Cisco Systems, CloudFlare, QUALCOMM, Google, MIPS Technologies, Athena Capital Research, > Gehtsoft, Neomantra, Wave Computing, OpenResty и еще куча Anon. *corporate* sponsor. > И без них у вас не было бы ни x64 port, ни > ARM port, ни MIPS port, ни всего остального важного и нужного. А кто сказал, что эти спонсоры были сразу? > При этом "main LuaJIT author (Mike Pall) is working on unrelated projects" > и даже деньги брать не хочет. > Ну сорян, нужная вам фича будет сделана... когда-то потом. Но это не > точно)) > Как вы думаете, кому нужно такая предсказуемость? Речь не об этом, перечитайте вопросы выше. Можно еще Фабриса Беллара вспомнить. Или Кента Дыбвига с chezscheme.
	Ответить | Правка | Наверх | Cообщить модератору

	172. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (172), 29-Май-25, 10:56
	> Дрю ДеВолт сравнивает Ну так это же... ДРЮ ДЕВОЛТ!!!111 Ему можно)) Но какой смысл? "qbe generates slower code compared to LLVM, with the performance ranging from 25% to 75% the runtime performance of comparable LLVM-generated code, depending on the workload." А каждый процент производительности - это огромное усложнение алгоритмов внутри компилятора. > А кто сказал, что эти спонсоры были сразу? А что было до того как они пришли? LuaJIT начали в 2005. Версия 1.х поддерживала только i386. First public release был LuaJIT 2.0.0-beta1 в 2009-10-31 и там все еще не было x64. x64 port появился в LuaJIT 2.0.0-beta3 — 2010-03-07 - как раз после того, как это оплатили корпы luajit.org/sponsors.html#sponsorship_x64 LuaJIT 2.0.0-beta6 — 2011-02-11 - PPC/e500 port, который внезапно тоже оплатили корпы. И так далее. Поэтому повторю вопрос, что было до того как пришли спонсоры?))
	Ответить | Правка | Наверх | Cообщить модератору

	179. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 12:38
	>> Дрю ДеВолт сравнивает > Ну так это же... ДРЮ ДЕВОЛТ!!!111 Ему можно)) Но какой смысл? > "qbe generates slower code compared to LLVM, with the performance ranging from > 25% to 75% the runtime performance of comparable LLVM-generated code, depending > on the workload." > А каждый процент производительности - это огромное усложнение алгоритмов внутри компилятора. QBE is a compiler backend that aims to provide 70% of the performance of industrial optimizing compilers in 10% of the code. >> А кто сказал, что эти спонсоры были сразу? > А что было до того как они пришли? > LuaJIT начали в 2005. Версия 1.х поддерживала только i386. > First public release был LuaJIT 2.0.0-beta1 в 2009-10-31 и там все еще > не было x64. > x64 port появился в LuaJIT 2.0.0-beta3 — 2010-03-07 - как раз после > того, как это оплатили корпы luajit.org/sponsors.html#sponsorship_x64 > LuaJIT 2.0.0-beta6 — 2011-02-11 - PPC/e500 port, который внезапно тоже оплатили корпы. > И так далее. > Поэтому повторю вопрос, что было до того как пришли спонсоры?)) Была база. Ты о чем споришь то? Что без корпов люди не смогут ничего написать? Смогут. Доказательства выше.
	Ответить | Правка | Наверх | Cообщить модератору

	182. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 12:51
	> QBE is a compiler backend that aims to provide 70% of the performance of industrial optimizing compilers in 10% of the code. Ну так это по словам самих QBE. Сам себя не похвалишь - никто не похвалить. А у Дрю почему-то цифры другие. Значит кто-то из них врет. > Была база. Ты о чем споришь то? Что без корпов люди не смогут ничего написать? > Смогут. Доказательства выше. Нет! То что у них получилось - было никому не нужное (ок, полутора землекопам было нужно), невероятно ограниченное васяноподелие. Пришли корпы и !внезапно! поделие начало развиваться)) Как же так? Может денег дали?)) >  Что без корпов люди не смогут ничего написать? Не без корпов, а без ресурсов. Но как показывает практика сообщество ресурсов не выделяет. А без ресурсов получается не ядро линя, а очередной хурд. Вы забавный(ая/ое). Пытаетесь доказать, что васяны сами все могут, а в итоге оказывается, что было какое-то васяноподелие, а потом в него вложились и оно стало нормальным. Или не вложились и оно так и осталось васяноподелием. Поэтому к вас вопрос - "Ты о чем споришь то?" Что для номальной разработки не нужны ресурсы? Что "сообщество" может их предоставить?
	Ответить | Правка | Наверх | Cообщить модератору

	186. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 14:30
	>> QBE is a compiler backend that aims to provide 70% of the performance of industrial optimizing compilers in 10% of the code. > Ну так это по словам самих QBE. Сам себя не похвалишь - > никто не похвалить. > А у Дрю почему-то цифры другие. Значит кто-то из них врет. И дальше что? QBE рабочий, компилятор C11 и hare это доказывают. Так что твои слова не подветрдились. Ты это понял и решил сменить пластинку, что где-то что-то не дотягивает до промышленных решений, в которые вливают кучи бабла с безграничными ресурсами. >> Была база. Ты о чем споришь то? Что без корпов люди не смогут ничего написать? >> Смогут. Доказательства выше. > Нет! То что у них получилось - было никому не нужное (ок, > полутора землекопам было нужно), невероятно ограниченное васяноподелие. Пришли корпы > и !внезапно! поделие начало развиваться)) Как же так? Может денег дали?)) Ну давай историю коммитов. Развивать софт и добавлять новые архитектуры != писать с нуля. С нуля он написал для конкретной архитектуры, которая ему была нужна. Доказал, что можно написать очень быстрый jit для динамического языка. Ты хочешь, чтобы он вот просто от нечего делать начал добавлять все возможные платформы? >>  Что без корпов люди не смогут ничего написать? > Не без корпов, а без ресурсов. Но как показывает практика сообщество ресурсов > не выделяет. > А без ресурсов получается не ядро линя, а очередной хурд. > Вы забавный(ая/ое). Пытаетесь доказать, что васяны сами все могут, а в итоге > оказывается, что было какое-то васяноподелие, а потом в него вложились и > оно стало нормальным. Или не вложились и оно так и осталось > васяноподелием. Могут, конечно. Выше уже есть доказательства. gcc не был под корпами изначально, ты вообще посмотри историю компиляторов. Автор luajit сделал многие оптимизации без всяких корпов, они уже подключились потом, когда увидели интерес для себя.
	Ответить | Правка | Наверх | Cообщить модератору

	188. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 14:51
	> И дальше что? QBE рабочий Еще раз, то что что-то рабочее, не значит что оно хорошее. QBE тормозной (на 30% по их же заявлениям и до 75% по словам Дрю) и никто в здравом уме его использовать в проде не будет. Он подходит только для хоббийных поделок вроде Hare. > компилятор C11 и hare это доказывают Компилятор для стандарта 12летней давности и хоббийный язычок? Что оно доказывает? > Так что твои слова не подветрдились. Именно это и подтверждает мои слова! Возможно у нас просто радикально отличаются понятия "нормальных", "рабочий" и тд. > Ты это понял и решил сменить пластинку, > что где-то что-то не дотягивает до промышленных решений Ну так все что не дотягивает до промышленных решений это и есть васяноподелки ¯\_(ツ)_/¯. Рад что хоть тут мы пришли к одному выводу! > в которые вливают кучи бабла с безграничными ресурсами. А без ресурсов сообщество как раз выдает васяноподелки. > Ты хочешь, чтобы он вот просто от нечего делать начал добавлять все возможные платформы? Все возможные платформы? У него даже x64 не было! > Могут, конечно. Выше уже есть доказательства. Где доказательства? Что чел сам не смог сделать x64? И смог только после оплаты? > gcc не был под корпами изначально, ты вообще посмотри историю компиляторов. Именно. И каким был GCC до того как в него начали вкладываться? А потом оказалось что без денег писать такой сложный компилятор как gcc не реально. Корпы со своей стороны были заинтересованы не писать с нуля, а довести до ума то что есть. Тоже самое было с llvm - была универская разработка, потом команду взяла на зарплату эпл и довели до production ready. Потом к эплу присоединились другие. А без эпла это был бы очередной канувший в небытие университетский проект, как сотни других. > Автор luajit сделал многие оптимизации без всяких корпов, Пруфы в студию)) > они уже подключились потом, когда увидели интерес для себя. Именно! Они из поделки сделали что-то, что можно использовать.
	Ответить | Правка | Наверх | Cообщить модератору

	187. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 14:32
	> Что для номальной разработки не нужны ресурсы? Что "сообщество" может их предоставить? Что такое "нормальная разработка"? Когда контора делает решения под себя как в Swift? Есть много примеров, где сообщество успешно разивает компилятор своего языка. Например, guile и guix.
	Ответить | Правка | К родителю #182 | Наверх | Cообщить модератору

	189. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 15:05
	> Что такое "нормальная разработка"? Когда контора делает решения под себя как в Swift? Мне было бы намного приятнее, если бы "сообщество" выдавало решение промышленного уровня. Но пока на выходе только хурды. Поэтому меня вполне устроит и альянс корпов. Главное чтобы продукт был стоящий. > Есть много примеров, где сообщество успешно разивает компилятор своего языка. Ахаха, много))) > Например, guile Классическое решение под себя от GNU. При этом никому кроме них не нужное - три гнутых поделия и какой-то EDA. gnu.org/software/guile/#apps-using-guile При том, что первый выпуск guile был еще в 1993 году. Да даже на расте софта больше написано чем на этом. Собственно что имеем - некое язычок, который за 30+ не получил распространения, не нашел себе места на рынке и используется только в пара софтин. Вы вот точно уверены, что это хороший пример "развития"? Или это скорее "задержка в развитии" или "нереализованные возможности"? > и guix. Еще более ненужное. Отличное дополнение к GNU Hurd. Даже обсуждать нет смысла.
	Ответить | Правка | Наверх | Cообщить модератору

	190. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 18:24
	>> Например, guile > Классическое решение под себя от GNU. При этом никому кроме них не > нужное - три гнутых поделия и какой-то EDA. gnu.org/software/guile/#apps-using-guile Вот опять в сторону уходишь. Речь же была про то, что есть не сделанная корпами реализация схемы (притом не одна) промышленного уровня.
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 18:29
	> не нашел себе места на рынке и используется только в пара > софтин. Пара софтин? Makefile, gdb, guix, shepherd, gnu mes.
	Ответить | Правка | Наверх | Cообщить модератору

	192. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 18:32
	>> и guix. > Еще более ненужное. Отличное дополнение к GNU Hurd. Даже обсуждать нет смысла. Ну вообще помимо дистра, это пакетный менеджер, который, например, для бутстрапинга использует bitcoin.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 01:38
	> Серьезных пользователей у него нет - пара сишный компиляторов с протухшими стандартами https://sr.ht/~mcf/cproc/ реализация С11, которая может компилировать gcc - "протухший компилятор"?
	Ответить | Правка | К родителю #151 | Наверх | Cообщить модератору

	170. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 09:35
	https://sr.ht/~mcf/cproc/ имеет проприетарную лицензию. Там всё закопирайчено. Такое нам не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	171. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (-), 29-Май-25, 10:34
	> реализация С11, которая может компилировать gcc - "протухший компилятор"? Т.е. к остальным утверждениям вопросов нет?)) Отлично! Ну, а так - да. Посмотрите на календарь, сейчас середина 2025 года. После С11 были C17 и C23. Понятно что в сишном мире могут сидеть и на С99... но это не делает С11 менее протухшим. А на счет компиляции gcc... какую версию он может компилировать? На сайте вроде указана gcc 4.7. GCC 4.7.0 - это March 22, 2012. Тоже свежак, аж пахнет)) Из поддерживаемых платформ x86_64, aarch64, и riscv64 (скорее всего из-за ограничений QBE) Причем из коробки оно сбилдить не может, нужен патченный GCC и немного костылей man.sr.ht/~mcf/cproc/doc/software.md#gcc-47 Сборка binutils ломает ABI (Note: this is a hack and won't be ABI-compatible with musl; things will break if any functions with long double get called. man.sr.ht/~mcf/cproc/doc/software.md#binutils) Что в итоге - компилятор, которые при некотором костылянии может собрать GCC тринадцатилетней давности. Достойно для исследовательского проекта, даже не сравнимо с gcc или llvm. ЧТД.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	174. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (158), 29-Май-25, 11:43
	>реализация С11, которая может компилировать gcc Очень интересно. В си нет ни продвинутого сборщика мусора, как в условной java, ни системы типов как в haskell или ocaml, ни каких-то аспектов многопоточности, типа erlang. Как я написал компилятор C за 40 дней - https://habr.com/ru/articles/274083/ У человека на восьмой день есть работа с указателями и арифметика, больше ничего. По идее, за несколько часов можно без опыта написать парсер, а потом тоже за несколько часов написать ассемблер, и собрать всё это за один день, ну за два, но человек это далал целых восемь дней. >День 25 >Я застрял на два дня с реализацией синтаксиса определений и объявлений без какого-либо успеха. Почему я не могу закончить это? Я сделал указатели и структуры за один день работы. Я чувствую что недооценил это. Может быть мне нужен план? >День 28 >Я пишу на C уже почти 15 лет, но только сегодня я почувствовал, что, наконец, понимаю синтаксис типов в С. Не удивительно, что я не мог писать работающий код. Это потому, что я просто не понимал его правильно. >День 73 >Безуспешно продолжал работать над компиляцией TCC. Конечно это тяжело, потому что если она пройдет, это значит мой компилятор имеет те же функции что и TCC. Компиляция других компиляторов полезна для отладки, но по своей природе она придираеся к каждой детали спецификации языка. Почему всё идёт так туго? Тут даже не то что стандарт старый, а даже сама возможность сборки другого компилятора является целой проблемой.
	Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

	178. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Кошкажена (?), 29-Май-25, 12:32
	>>реализация С11, которая может компилировать gcc > Очень интересно. В си нет ни продвинутого сборщика мусора, как в условной > java, ни системы типов как в haskell или ocaml, ни каких-то > аспектов многопоточности, типа erlang. > Как я написал компилятор C за 40 дней - https://habr.com/ru/articles/274083/ > У человека на восьмой день есть работа с указателями и арифметика, больше > ничего. По идее, за несколько часов можно без опыта написать парсер, > а потом тоже за несколько часов написать ассемблер, и собрать всё > это за один день, ну за два, но человек это далал > целых восемь дней. Как тему то стал менять. Как уж на сковородке завертелся.
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (-), 29-Май-25, 12:40
	> Как тему то стал менять. Как уж на сковородке завертелся. Это другой аноним влез, я Аноним (-). Хотя про убогость сишки и ее недостандарта он прав. Но нет смысла обсуждать очевидное.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	+/–
	Сообщение от Аноним (158), 29-Май-25, 13:27
	>Как тему то стал менять. Как уж на сковородке завертелся. Во-первых, я не меняю тему, так как другие сообщения в этой ветке писал не я. Во-вторых, хотя сишники очень любят козырять стандартом, как видно на примере этих самодельных компиляторов, то получение любого, пригодного хоть сколько нибудь практического применения компилятора - вопрос не тривиальный. Вы почему-то игнорируете, как скорость разработки, так и качество получившегося результата. Почему? Почему у сишников такая любовь к полурабочим велосипедам?
	Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

106. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–4 +/–
Сообщение от Аноним (106), 28-Май-25, 17:17
Это было бы не так забавно, если бы в школах не мучали детей написанием сортировки тем или иным методом. А так выходит, любой ребёнок может, а деды не смогли.
Ответить | Правка | Наверх | Cообщить модератору

	115. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–2 +/–
	Сообщение от Аноним (115), 28-Май-25, 17:35
	В школах этим не занимаются. Ваше "если" не выполняется. Весь комментарий бессмысленный.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (119), 28-Май-25, 17:57
	> В школах этим не занимаются. Ваше "если" не выполняется. Весь комментарий бессмысленный. Сударь, вы - трепло! ФЕДЕРАЛЬНАЯ РАБОЧАЯ ПРОГРАММА СРЕДНЕГО ОБЩЕГО ОБРАЗОВАНИЯ ИНФОРМАТИКА (базовый уровень) (для 10–11 классов образовательных организаций) Раздел 3. Алгоритмы и программирование Сортировка одномерного массива. Простые методы сортировки (например, метод пузырька, метод выбора, сортировка вставками). Это есть любой нормальной школе, которая следует федеральной программе! В каком хлеву вас обучали?
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Уязвимость в GNU sort, приводящая к выходу за границу буфера"	–1 +/–
	Сообщение от Аноним (130), 28-Май-25, 18:38
	>> В школах этим не занимаются. > ИНФОРМАТИКА (базовый уровень) (для 10–11 классов образовательных организаций Если этот персонаж поди после 9 класса в ПТУ отправился, то откуда ему знать, что там на информатике в школах преподают? 😂
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема