URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 132652
[ Назад ]

Исходное сообщение
"Уязвимость в утилите GNU split, приводящая к переполнению буфера"

Отправлено opennews , 24-Янв-24 10:18 
В утилите split, поставляемой в пакете GNU coreutils и применяемой для разделения больших файлов на части, выявлена уязвимость (CVE-2024-0684), приводящая к переполнению буфера при обработке длинных строк (несколько сотен байт), в случае использования в split опции "--line-bytes" ("-C"). Уязвимость была выявлена в ходе анализа сбоев, возникающих при использовании утилиты split для разделения данных, передаваемых при помощи QR-кодов...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=60490


Содержание

Сообщения в этом обсуждении
"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 10:18 
То ли ещё будет когда split научат с Unicode работать, точно наступят на все возможные грабли, как наступили в sort. Сейчас split только байтовые счётчики поддерживает и корежит при разделении текст в многобайтовых кодировках.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено adolfus , 24-Янв-24 11:44 
А что с sort не так? Просто указываешь какой LC_COLLATE нужен и все. Или еще короче -- LANG
$ LANG=C sort file

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 15:27 
> А что с sort не так?

https://bugzilla.suse.com/show_bug.cgi?id=928749


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Бывалый смузихлёб , 25-Янв-24 10:28 
> cwrite (n_out == 0, hold, n_hold);
> n_out += n_hold;
> - if (n_hold > bufsize)
> -   hold = xirealloc (hold, bufsize);
> n_hold = 0;
> - hold_size = bufsize;

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

В итоге окажется что какой-то очередной эксперимент по впиливанию незаметных дыр в попенсорс
Или - откровенная криворукость и отсутствие внятного тестирования


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено cheburnator9000 , 24-Янв-24 10:26 
Срочно переписать на rust.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено НяшМяш , 24-Янв-24 10:39 
Уже: https://uutils.github.io/coreutils/book/utils/split.html

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 10:47 
v0.0.24
что именно тут уже ?

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 12:08 
> v0.0.24
> что именно тут уже ?

Уже в версии v0.0.24 дыреней меньше, чем в coreutils 7.2.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 12:16 
как вы это определили ?

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 18:06 
По размеру, очевидно же. Просто умалчивают о маленьких дырочках, более приятных в использовании.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 16:44 
Пользуюсь полгода, всё отлично работает

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:02 
я пользуюсь оригинальной coreutils и представьте тоже всё отлично работает

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:49 
Так на здоровье, рад за вас.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Вы забыли заполнить поле Name , 24-Янв-24 16:21 
Готов поспорить ты этим не пользуешься

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 16:44 
Ну я пользуюсь, задавай вопросы.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:41 
>Срочно переписать на rust.

Не дождёдесь. Эти скорее на Guile перепишут.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 16:17 
Мы перепишем на любом языке, который имеет одобрение Столлмана и имеет строгую, непримиримую по отношению к проприетарщикам и пермиссивщикам, лицензию.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:51 
Guile, common lisp. Вперёд. Это не должно быть очень сложно)

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:03 
На CL такое действительно пишется за вечер, с тестами и документацией.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:08 
не рассказывайте им )))

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 21:47 
Ну собственно я знаю. Но обычно те кто "лишь бы батька одобрил фар фап" умеют писать только на матерном русском.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 18:48 
Забавно, но у Guile, несмотря на то что это "гнушный" язык , лицензция как раз таки совместимая с проприетарщиной и пермессивщиной. И ментейнеры его, насколько я знаю, со Столлманом не особо дружат.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 18:59 
Ну так LGPL это наверное единственная гну лицензия, не похожая на раковую опухоль.
Удивительно что поехавшие вообще разрешили ее создать.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 21:50 
Не удивительно. Это единственная лицензия, которая 1) является одобренной гну 2) позволяет бороде получать лавандос напрямую от компаний, а не откаты от универов как он привык. Самое смешное, что это схема не работает. В принципе это всё что надо знать о его умственных способностях.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 23:24 
Согласен, план очень тупой, но что-то мне подсказывает, что ты его сам только что нафантазировал. Потому что доходы деда абсолютно никак не зависят от того, какие лицензии использует гнутый софт. Дед как бомжевал с донатов с fsf, так и продолжает бомжевать.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Вы забыли заполнить поле Name , 24-Янв-24 17:56 
>>Срочно переписать на rust.
> Не дождёдесь. Эти скорее на Guile перепишут.

Как будто это плохо.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 10:37 
Нет, ну а что хотят уважаемые эксперты по Си? Сишка - сложный системный язычок, чтобы на нём писать, погроммист должен 150 раз обдумать поведение каждой строчки на выход за пределы, переполнение, нулевые указатели-сегфолт, деление на ноль и т.д. и т.п. На написание полностью безопасной утилиты на Си нужно много лет работы лучших инженеров по Си, вот так то...

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 10:49 
Другое дело раст: мозги в принципе не включают, считая что safe магия их спасет от всех проблем, а она почему-то не работает, да ещё новые проблемы добавляет. Так ещё и гораздо медленнее. Но в каждой новости конечно хруст надо приплести, который с 2014 года использовался только во всякой ерунде.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 10:53 
Причём тута раст? Я пишу про сишку! Тебе раст просто мерещится! Кроме раста есть плюсы, хоть громоздкие, но там есть сморт пойнторс и RAII, а сишка - это же вообще технология без всякой защиты. Язычок из 80-х годов.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 11:38 
> а сишка - это же вообще технология без всякой защиты

то что надо для написания ядер ОС и драйвер. А всякие умные указатели и прочие RAII - это всё для прикладухи, а не для системщины.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 11:41 
> то что надо для написания ядер ОС и драйвер.

Да, именно то что нужно!
Чтобы дырень в твоем драйвере, написанном лучшими погромистами из имеющихся, рутанула тебе всю ОСь))


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 12:01 
ОЙ, да не завидуй ты так. Ты ни на каком языке никакого драйвера не напишет, даже на самом безопасном.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:55 
Лучше тот, кто не пишет драйверов, чем тот, кто пишет их на сишке.
Первый хотя бы не делает хуже.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:02 
Ты получается круче всех инженеров в IBM/RedHat. Я горжусь, что живу в одно время с такими людьми и имею возможность с ними на форуме общаться.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 18:01 
Он прав. Ядра ОС это пожалуй единственная ниша для сишки. Драйверы - нет.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено adolfus , 24-Янв-24 12:35 
Если внимательно читать IEEE Std 1003.1 aka POSIX и разного рода rationale про функции системного интерфейса, то там обращается особое внимание на то, что никаких проверок на входе в функции системного интерфейса (в числе которых, кстати, и содержимое libc) чтобы предотвратить ситуации, которые в стандарте языка си описаны как "неопределенное поведение" и "ошибки", не производится -- это ответственность программиста.
Так что если не согласны с такого рода положением, к вашим услугам разного рода фреймворки, написанные, кстати, на си, поверх той же самой libc.
А не изучив стандарты на си, на c++ и posix нефиг рассусоливать про какие-то "безопасные" языки. Под этими "безопасными" языками (за редким исключением экзотических архитектур)  лежит тот-же "небезопасный" си и "небезопасная" libc.
НЯП, настоящих языков программирования, компиляторы которых написаны на них же или на ассемблере, меньше десятка -- С, C++, FORTRАN, COBOL, несколько виртовских языков и все. Остальное -- обертки над ними, но большей частью над С и С++. Кстати, есть такой стиль программирования -- backend+frontend. Вот, например, питон -- он четко следует именно такой парадигме -- внизу в качестве бакенда c+libc, сверху он -- фронтенд.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено stalinus , 24-Янв-24 19:32 
Всё верно, но зря ты так подробно расписал. Анонимы opennet читают первые десять слов, а дальше у них происходит переполнение буфера со стиранием уже прочитанного.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 23:20 
> "дальше у них происходит переполнение буфера со стиранием уже прочитанного"

Они что тоже на СИ написаны?
Вот это откровение!
Но тогда понятно почему некоторые настолько дырявые)


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено berium , 25-Янв-24 05:30 
Переполнение буфера реализуется в коде на любом языке программирования, даже Rust от этого не спасёт.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 23:51 
Тебе про Фому, а ты про сисколы. Да еще и человека соблазнил тебе чаю подлить.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 12:16 
А сишники забавные ребята. Каждый раз когда ты начинаешь их мордочкой тыкать в их... эээ... код, они начинают верещать про раст, про его проблемы, то что он не серебрянная пуля и тд.
Мы тут не раст обсуждаем, да и кроме него есть еще другие языки.
Скажите уже что-то дельно в оправдание дыряшки. А пока что мозги не включают сишники.

PS. хруст первым приплел ты))


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено berium , 25-Янв-24 05:39 
Нет разницы кто и кого первым приплёл.

Когда кодовая база на языке "ВАШЕНАЗВАНИЕ" достигнет объёмов кодовой базе на C/C++, тогда можно будет сделать какие-то выводы.

В будущем Rust займет какую-то нишу, но она будет существенно ниже C/C++, т.к. в последние года произошло размытие проектов по разным языкам программирования, а не как в 80/90-ых выбор между пятеркой языков, из которых два лидировали с колоссальным отрывом.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Советский инженер , 25-Янв-24 10:30 
>Нет разницы кто и кого первым приплёл.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Совершенно другой аноним , 25-Янв-24 13:06 
>>Нет разницы кто и кого первым приплёл.
> разница есть. потому что такая ошибка, как описана (креш на некорректных входных
> данных), должна выявляться на этапе тестирования, которого, очевидно нет. и да,
> язык программирования тут уже ничего не исправит, просто кодеркам похер на
> качество.

Тесты у них есть, как минимум с 1993 года. Ошибка была внесена в coreutils 9.2 (2023-03-20). Очевидно, именно эта ситуация не тестируется.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Советский инженер , 25-Янв-24 18:22 
>Тесты у них есть

ага, есть но мягкий ...


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 13:27 
> Сишка - сложный системный язычок, чтобы на нём писать, погроммист должен 150 раз обдумать поведение каждой строчки на выход за пределы, переполнение, нулевые указатели-сегфолт, деление на ноль и т.д. и т.п.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 11:23 
xrealloc xpalloc... Это какой же должен быть пипец я языке чтобы было столько всяких от alloc от AAalloc до ZZalloc

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 11:33 
Надо запретить люядм писать свои аллокаторы, sbrk и mmap хватит всем. И да, их тоже нельзя писать, надо просто купить и скачать единственно верную реализацию

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено нах. , 24-Янв-24 11:41 
они в ведре, к сожалению, а не в языке.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 11:58 
> они в ведре, к сожалению, а не в языке.

Да понятно, просто чел возникал изначально, что людям дали malloc(), а им мало, они еще что-то там своё пишут. Плохой язык C, на нем можно свой аллокатор написать, если по какой-либо причине тебя не устраивает тот, который в libc


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено пох. , 24-Янв-24 12:38 
главное не говорите ему, что исходник alloc() есть в книжке k&r как образец совершенно тривиального Си кода для обучения.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:49 
Кстати, сколько дыр в этой реализации? Наверное, с десяток.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено нах. , 24-Янв-24 11:37 
это не в языке, дурашка, это - в головах.
В процессоре нет никакого alloc, представляешь - вообще.

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

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



"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 12:43 
Да, да, это все новое "новое альтернативно одаренное поколение"
А кто писал шикарнейший код типа Dirty COW (CVE-2016-5195) которая жила с ядра 2.6.22?
А кто выпрограммировал sock_sendpage (CVE-2009-2692) который жил с 2001 по 2009?

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:26 
> А кто писал шикарнейший код типа Dirty COW (CVE-2016-5195) которая жила с ядра 2.6.22?
> А кто выпрограммировал sock_sendpage (CVE-2009-2692) который жил с 2001 по 2009?

Ахахахах, а ты вообще ничего не написал, ахахаха


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:43 
А где ваши доказательства? (с)
Без пруфов это просто газификация лужи, что в принципе от лиютеля дыряшки и ожидалось)
Но оправдывать кал-лег бракоделов это у вас принято, как я понял.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:53 
Как говорят це-разработчики, "от всех этих дыр нам же только луДше!!1"

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:17 
Так правильно говорят!
Чем запутанее код и чем больше там непонятных багов - тем меньше шансов, что такого уволят.
Но даже если и уворят, то он найдет себе такой же проект написанный через одно место и будет сидеть на его поддержке годами.

Ты почитай на чем должны зарабытывать ГНУтики, согластно манифесту коммуняки столмана.
Правильно "на поддержке".
А чтобы поддержка и денюжка не закончились, то баги тоже не должны заканчиваться.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 12:48 
> это не в языке, дурашка, это - в головах.

Полностью согласен!
В головах у сишников, очевидно, опилки. Тк на протяжении 30-40 лет делать одни и те же ошибки...
Это надо явно обладать альтрнативным мышлением.

К сожалению целое поколение (а то и два) таких альтернативно одаренных сейчас сидит и пишут системы, от которых требуется максимальная надежность.
Но хуже того - они противодействуют любым попыткам как-то изменить ситуацию - тк в этом случае все их знания о 193 Undefined Behavior в C99 становятся ненужными и они могут идти работать дворниками.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:51 
> в этом случае все их знания о 193 Undefined Behavior в C99 становятся ненужными

А были ли знания? 99% сишников про UB не задумываются. Если программа не падает на его компе и его входных данных, то она считается стабильной.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:59 
Я тебе сейчас тайну открою. 99% сишников пох, даже если падает. И не только сишников, потому что иди нах, задачу решает. Тратить время на нештатные случаи и маловероятные ситуации стоит только когда это является проблемой.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:22 
Отличное описание типи-кал СИ разработки.
Сначала зачем "Тратить время на нештатные случаи и маловероятные ситуации", а потом:
- у нас хартблид у половины интернета
- почти все андроид телефоны оказывают дырявыми
- машинки тойоты разгоняются сами по себе и убивают людей

Имеено поэтому такой подход должен помереть (вместе с бракоделами)


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:33 
> Имеено поэтому такой подход должен помереть (вместе с бракоделами)

И кто останутся? Один ты, ничего не написавший?


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:39 
Повторюсь, чем писать дырявый код, лучше не писать код вообще.
Поэтому, если удалить всех сишников (например, переквалифицировать в дворники), мир станет лучше.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:44 
Свято место пусто не бывает)
Как сказал Линус - мы седые и старые, надо готовить молодеж на замену.
И добавил раст в ядро.
Вот новое поколение и будет писать.

> Один ты, ничего не написавший?

То что я написал уже 10 лет работает, так что мне есть чем гордиться.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 15:19 
Коллега, гордыня до бобра еще никого не довела. Начиная с прегордого денницы. Пустое это!
Лучше смотреть на это с радостью о том, что соделанное с Вашей помощью приносит пользу. Разница в пропасть. Попробуйте, почувствуете положительную динамику!

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 15:50 
Так я горжусь, что пол ляма народу ежедневно пользуются)
И это упрощает им жизнь, освобождает время на полезные делала - с детьми посидеть, кино посмотреть, на свидание сходить)
Я полностью понимаю, что это не лучший код в мире, так что без гордыни, но как говорится "это немного, но честная работа"

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 16:44 
Плин, ну ты вспомнил. Я, до того как переехал в Европу, в России сменил больше 10 фирм. И в двух последних моим софтом до сих пор пользуются каждый день 24/7, который экономит компании деньги на коммерческих альтернативах. И да пользуются им дохера народу, кто является их клиентами, даже не подозревая об этом. Но я про такое говно даже не вспоминаю и не горжусь

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:03 
Ну не гордись) Я ж тебя не заставляю.
Просто когда из этих людей есть например наса или церн - то уже повод.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:00 
>Так я горжусь
>так что без гордыни

Не то чтобы я задроttством каким занимаюсь и к словам придираюсь, но на самом деле вопрос действительно важный. Когда-то тоже много чем гордился. Считал себя нереально вумным, як вутка и вот это все.
Но к счастью Господь не оставил и вразумил.
Теперь, чтобы я не делал, делаю как для Бога и с пониманием, что сам по себе лишь инструмент в Его руках, реализующий Его волю. Являясь при этом лишь сосудом всякой нечистоты.
Лучше не дожидаться жесткого вразумления.

Вопрос в отношении и восприятии себя и своего труда. Что основа, а что следствие.

Тогда и покой и радость внутренняя будет от результата. Да и в целом.
Не путаем эту внутреннюю радость скажем с отжигами лучших блудниц и прочих там няшностей. Это другое.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:34 
Не, сорри.
У меня выдуманные невидимые друзья закончились еще в детстве.

Ну т.е в такого бога как описывают я не верю.
Особенно видя что в мире происходит (жестокость, насилие и тд).
Но, а вот если представить, что он просто злой, создал несовершенных существ, наказал их за несовершенность (которую сам добавил) и теперь наслаждается их страданиями...
Вот в такого Бога я бы поверил. Даже в то что некоторых людей он создал по образу и подобию)


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:56 
Здесь как Вам будет угодно. Просто из собственного опыта рекомендовал.
Недавно узнал, что и друзей кроме Бога то нет. все имеют свою цену. Кто в денежном эквиваленте а кто и в иных единицах.

Догматическое представление Вы обрисовали неверно. Но в эти дискурсы вдаваться тут не будем. Просто почитайте, при случае источники.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Серб , 24-Янв-24 15:23 
> Как сказал Линус - мы седые и старые, надо готовить молодеж на замену.
> И добавил раст в ядро.
> Вот новое поколение и будет писать.

Только вряд ли на rust.

Это хороший способ переманить разработчиков. Потыкаются. Замучаются с поддержкой множества архитектур и вариантов конфигурации ядра и:

1) или сделают rust нормальным языком (что вряд ли, тяжко существующие решения с необходимыми требованиями связать)

2) или начнут использовать существующие наработки в ядре.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено нах. , 24-Янв-24 13:58 
> К сожалению целое поколение (а то и два) таких альтернативно одаренных сейчас сидит и пишут системы

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

> Но хуже того - они противодействуют любым попыткам как-то изменить ситуацию

потому что пока что попытки сводятся к "давайте заставим их писать как НАМ хочется". От тех кто не умеет ничего кроме coc.md и мертворожденных переписываний того что в переписывании не нуждалось.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:33 
> ну так ты-то ничего кроме комментов на опеннете не умеешь... а ресдох, написанный "правильным" поколением - почему-то сдох. Что ж ето деется - никому, оказывается, даром не нужна безопастная ось? Попробуй приплачивать?

Инертность мышления + то что во всяких коммитетах и ядре сидят такие же престарелые дундуки.
Которые боятся уйти на пенсию и пишут "у Раста сложный синтаксис, я нипонимать((( мони дедовые мозги не позволяют мне выучить что-то новое".
Но процесс пошел, корпам надоели вечные дыряшки.

> потому что пока что попытки сводятся к "давайте заставим их писать как НАМ хочется".

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

> От тех кто не умеет ничего кроме coc.md и мертворожденных переписываний того что в переписывании не нуждалось.

Жалкие оправдания криворуких бракоделов)
Если аргументы закончились сведи все к COC.md
А учитывая что он есть в ядре docs.kernel.org/process/code-of-conduct.html, фряхе freebsd.org/internal/code-of-conduct/ или даже node-которая-js github.com/nodejs/admin/blob/HEAD/CODE_OF_CONDUCT.md
То приходим к неутешимому выводу - для успешности проекта оно необходимо.
Ну чтобы затыкать рот всякому невоспитанному б-лу.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 24-Янв-24 16:20 
Я вам повторю, поскольку до вас никак не доходит.

30 лет назад была куча безопасных языков, и 20 лет назад тоже.
Я обожал Visual Basic, целиком и полностью супер язык, супер IDE, супер справка.
Была только одна проблема: или ты пишешь на С или оно работает медленно и весит много. А проги тогда распространялись дискетами.
Иногда тяжёлые вычисления выносили в DLL на С а гуй оставляли на чём то более высокоуровневом.

Этот ваш раст в те времена даже скомпелячить нельзя было, ресурсов бы не хватило.
И пользоватся им тоже было бы не возможно - он дико тормозной, ждать пока он соберёт хелло ворлд за 20 минут никто бы не стал.
Вся безопасность раста свелась бы к тому, что код написанный на нём даже не собрался а если и собрался то не запустился :)

И сейчас, не смотря на все кудахтанья, успехи раста сводятся к порче отдельных С/С++ проектов, которые теперь и собирать трудно и поддерживать не возможно из за смешения языков.
Всё что делают растоманы - это греют воздух и сжирают производительность.
Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке.
В плане поддержки это полная абракадабра.

Фишка программ на С в том что они быстро и везде собираются, синтаксис понятен любому идиоту, и ошибки относительно легко исправляются, особенно современными инструментами.
У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Советский инженер , 24-Янв-24 16:58 
>синтаксис понятен любому идиоту

время идиотов в кодинге прошло

>ошибки относительно легко исправляются, особенно современными инструментами

все упоротые сишники все время рассказывают про эти современные инструменты, но элементарного fuzz testing так и не осилили на таком важном проекте !!!

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 24-Янв-24 20:18 
> время идиотов в кодинге прошло

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


> все упоротые сишники все время рассказывают про эти современные инструменты, но элементарного fuzz testing так и не осилили на таком важном проекте !!!

Это ваша оценка.
Моя оценка отличается: я не боюсь ошибок в программах и то что программы падают.
Там где критично - пусть производитель делает +1 резервирование, остальное перезагрузят/перезапустят пользователи.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 23:23 
Предположим, пользователи перезапустят.
А что делать с уязвимостями типа heartbleed?
Когда в один момент выясняется, что половина шифорвания была уязвима?
Не думаю, что вы бы обрадовались "о, прочитать мою почту, майору, провайдеру и вообще кому угодно стало проще".

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 25-Янв-24 01:09 
Ничего, всё исправят в своё время, как обычно.

> Не думаю, что вы бы обрадовались "о, прочитать мою почту, майору, провайдеру и вообще кому угодно стало проще".

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


> Или например удаленноен получение рута через уязвимость браузера, хорг сервера и тд.

И что?
Перезагрузить, переустановить.
Всё как обычно.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:10 
Вот вроде говорите правильные вещи, но выводы из них делаете... мама родная...
Да 30 лет назад сишка захватила мир, потому что можно было быстро наыдлокодить программу.
Уже тогда была ада, но просто на ней писать было сложнее, а идиотов оказалось больше.
Да 20 лет назад не было таких мощностей как сейчас.
Ну и проекты были маленькие - сравните ядро тогда и сейчас.

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

Сишники не в состоянии следить за памятью в больших проектах.
Да в общем-то никто не в состоянии, просто только сишники упорно пытаются доказать всем, что именно они могут и как всегда жиденько...
Они обязательно где-то накосячат, хотя правила до тупости просты:
- один раз память выделил - один раз очистил, не больше и не меньше
- за пределами выделенного не читай
- за пределы выделенного не пиши
И всё! Просто сложность проекта не позволяет это всё удержать в голове.
Эта очередная новость - тому доказательство.

> Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке.

Невозможно свести ноль в ноль. У си никакого прогресса за 20 лет не было.
У плюсов был и довольно большой. Но не у дыряшки.

> и ошибки относительно легко исправляются

Ошибки нужно не делать, а не сначала делать, а потом легко исправлять.
Плюс посмотри по сколько лет эти ошибки живут в проектах. Годами! И их никто не замечает.

> У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.

Раст долго собирается как раз потому, что он делает куча проверок в compile-time, в отличие от сишки.
Но в рантайме он сравнимо быстр. И это уже не вопрос, это утверждение.

А несъедобен синтаксис у него только для закостенелых мозгов.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 24-Янв-24 21:04 
От того что у вас мобила лишний раз перезагрузится или приложение в ней - ничего страшного не случится.
Вот и вся цена ошибок.
Не надо раздувать из мухи слона.


> Невозможно свести ноль в ноль. У си никакого прогресса за 20 лет не было. У плюсов был и довольно большой. Но не у дыряшки.

Я вообще то про прогресс вычислительной мощности который раст помножает на ноль.
Самому С развиватся особо и не надо, С++ прекрасный пример того как делать нельзя. Но вот раст упорно делает как С++ при этом заявляя себя заменой всему.


> Плюс посмотри по сколько лет эти ошибки живут в проектах. Годами! И их никто не замечает.

И никому не мешают, так бы нашёлся кто то кто сам починил или заплатил.


> А несъедобен синтаксис у него только для закостенелых мозгов.

Есть множество примеров с обычными языками и письменностями.
Раст это азиатские иероглифы, против С - простого и лаконичного как английский.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 23:26 
У вас через браузер, через вьювер картинок или через пдф-просмоторщик уведут пароли, взломают банкинг, взломают сервак через специально оформленный пакет.
Вот и вся цена ошибок)))

> Я вообще то про прогресс вычислительной мощности который раст помножает на ноль.

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

> Самому С развиватся особо и не надо

Ну-ну. А когда в си появятся... напр. нормальные enum, а не убогая обертка над числом? Или associated value?
Или это излишество, типа деды и без них прожили и нам не нужно?
Вообще, тот кто не развивается, то в итоге вымирает.

> Раст это азиатские иероглифы, против С - простого и лаконичного как английский.

Уверен на 95% что вы или ничего не писали на расте, или писали какой-то hello world.

> простого и лаконичного как английский

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 25-Янв-24 01:18 
> У вас через браузер, через вьювер картинок или через пдф-просмоторщик уведут пароли, взломают банкинг, взломают сервак через специально оформленный пакет.

Мой банковский счёт не стоит таких усилий, будем честны, и ваш тоже :)


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

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


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

Так вы щас топите против опенсорца, потому что возможность самостоятельно собрать один из основных критериев свободы.
А гниль настолько тормозная что ещё немного и сборка будет проходить только у бигкорпов на топ500 компах.


> А когда в си появятся... напр. нормальные enum, а не убогая обертка над числом? Или associated value?

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


> Вообще, тот кто не развивается, то в итоге вымирает.

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



"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 11:04 
> Мой банковский счёт не стоит таких усилий, будем честны, и ваш тоже :)

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

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

Те критерии свободы от поехавших комми и чуваков, которые пытались копирайтить само слово опенсорс, я не признаю. Для меня open source это один критерий - код открытый.
Но даже так "свободу собрать у себя" никто не забрал. Подумаешь какой-то гентушник попердолится на час больше.

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

Так пусть минималисты пишут свое ядро только на СИ, а мы будем писать свое ядро на СИ  и Rust.
Раз вы такие крутые то сделать форк и поддерживать самим вы точно справитесь)

> Расскажите это обилию растительности и живности вокруг вас.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 25-Янв-24 20:53 
> Эксплойт может работать в автоматическом режиме, и ему будт пофиг у вас на карточке 100 рублей или 100 тысяч.

Это так не работает в банками, только щиткойнами.
Там нужна цепочка чтобы по быстрому перевести и вывести в нал, ради 100 руб никто возится не будет.
И у меня банки вечно требуют СМС при любом переводе за пределы своих счетов в одном банке.


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

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


> Так пусть минималисты пишут свое ядро только на СИ, а мы будем писать свое ядро на СИ  и Rust.

Чото вашего ядра нигде не видно, только на чужом паразитируете.


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

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Совершенно другой аноним , 25-Янв-24 09:56 
> Да, английский может проще чем иероглифы, но простым и лаконичным его уж точно назвать нельзя.
> Местами он существенно сложнее, чем напр. японский.

Прошу прощения, так-сказать на правах лингвиста, боюсь, что японский ни в чём не проще английского. Вот уж где, на самом деле, наркомания во все поля. Насколько я понимаю, даже китайский попроще будет. Для затравки - https://habr.com/ru/articles/673446/. Там ещё есть две части с продолжением, если вдруг станет интересно: https://habr.com/ru/articles/678716/ и https://habr.com/ru/articles/683820/


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 12:02 
Прошу прощения, но на правах учащего японский и знающего английский на уровне средний+, все равно считаю, что МЕСТАМИ японской ДЛЯ МЕНЯ проще чем английский. Напр. глаголами.



"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Совершенно другой аноним , 25-Янв-24 13:05 
Ну вроде как идея была правильная - все глаголы заканчиваются на "る", но потом, внезапно оказалость что это не так, и есть глаголы, условно заканчивающиеся на "う", потом там ещё один вид глаголов есть, если помню правильно. А потом ещё оказалось, что окончания глаголов меняется, причём очень сильно по-разному в зависимости от контекста и времени (всякие там った дорисовываются, а предыдущие окончания отбрасываются). Так-что позвольте с Вами не согласиться - там и с глаголами полный порядок.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено жабабыдлокодер , 24-Янв-24 23:40 
Мобила лишний раз перезагрузится, томограф неправильные данные передаст, искусственная почка зависнет, автопилот на середине маневра отключится. С точки зрения человечества - человечество не заметит, да.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:20 
> 30 лет назад была куча безопасных языков, и 20 лет назад тоже.

Да они и сейчас есть, Ада например (и особенно Spark Pro).
Но, к сожалению, в ядро попала отвратительная дыряшка, которая теперь множит дыряшки для пользователей.

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

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

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

Максимально бредовое утверждение. Тут уже кидали ссылки и на андроид. и на драйвер для М1 который прошел сертификацию кроноса, и на кучи утилит (от амазона, RustVMM, до ядра Maestro)

> Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке.

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

> В плане поддержки это полная абракадабра.

Просто так скажи "я неосилятор, у меня мозг усох и нового я освоить не могу".

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

Хахахаха, кажется у тебя упал красный нос 🔴, возьми пожалуйста.
Уязвимости живут в ядре по 5-10-15 лет. В овнопроектах типа хорг - так вообще 35.
И где эти ваши инструменты?

> У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.

Нет, нет и нет)
Безопасность там именно такая как обещали.
Скорость там сравнимая, можешь просветиться на benchmarksgame
То что ты не моешь осилисть синтакс, так ты наверное просто старый.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 25-Янв-24 01:04 
> Можно и на улицу в кустики бегать, но люди предпочитают нормальный санузел.

Так проблема в том, что вы этот санузел пытаетесь изуродовать со словами:
- как бы мимо никто не пописал, потому надо писать сидя, вставляя катетор
- как бы микробы не размножились потому надо перед использованием 10 дней проводить дезинфекцию а после использования нужно сносить и перестраивать заново


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

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


> Уязвимости живут в ядре по 5-10-15 лет. В овнопроектах типа хорг - так вообще 35.

И кому они помешали?


> Скорость там сравнимая, можешь просветиться на benchmarksgame

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:55 
Кто о чем, а вшывый о расте.
А ведь в коменте на который ты отвечал ни слова о расте.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:56 
Можно было просто написать "раньше было лучше, а теперь гогно, хотим быть идиотами" и получилось бы то же самое, но без балабольства.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 23:59 
> Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке.

Нет, это тебе следует понять, что ты отстал от прогресса лет на 20 или больше. Ты когда в последний раз открывал учебники по Computer Science? Когда в последний раз интересовался теорией того, как можно добиваться от программы предсказуемого поведения? Когда в последний раз интересовался тем, как эта теория в практику претворяется?

Ты рассуждаешь о каком-то визуалвасике, который уже лет двадцать неактуален. И не потому, что раст пришёл и всё испортил, васик сам умер. Всякие там C# его подвинули.

> Была только одна проблема: или ты пишешь на С или оно работает медленно и весит много.

Это давно уже не проблема, потому что интерпретаторы остались в прошлом, нонче байткоды и jit, aot, и тому подобные штуки. И языков на выбор -- python, go, C#, Java, Kotlin, ...

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

Враньё от начала и до конца.

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

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

> ошибки относительно легко исправляются

В hello-world -- да, легко. Если ты сможешь их там найти, прячущимися за иллюзией понятности синтаксиса. В чём-то более сложном... Когда ты выясняешь, что программе сегфолтится, потому что какой-то индекс хранящийся в памяти имеет совершенно невозможное значение: вся программа написана так, чтобы такого значения там не возникало, но де факто оно появляется и это приводит к сегфолту. Вот успехов тебе отлавливать это. Сначала ты найдёшь место, которое пишет это значение туда, и в этом месте окажется вполне корректный код, просто на входе он получает инвалидный указатель. Потом ты полезешь отлавливать источник этого указателя, а потом источник того, что этот источник сбило с толку...

Тебе просто не приходилось отлаживать код, который писали "эксперты" C/C++, которые забыли выработать в себе параноидальное следование принципу KISS. Чтобы вот тех ситуаций не случалось бы, программисты должны до панических атак бояться любых структур данных, сложнее массива. Но сколько же их таких ходит, кто начинает выпиливать более сложные структуры данных, чем они в состоянии отладить. Кто-то из них в рамках преждевременной оптимизации это делает, кто-то по каким-то идейным соображениям, кто-то вообще никаких причин тому назвать не может, но на KISS кладёт болт. И в C++ с этим хуже, поскольку там гораздо проще наворотить сложностей.

> У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.

Если для тебя заверения раста о безопасности, то это значит, что ты их не понимаешь. Раст позволяет инкапсулировать инварианты (чтобы ровно в одном модуле о них думать), и задать ограничения на использование API крейта, которые будут проверяться борроу-чекером. Это всё, что в расте есть для безопасности, и это то, что реально работает.

Насчёт скорости -- ты откровенно врёшь, я уверен сам не веришь в свои же слова.

А несъедобность синтаксиса, объясняет нам, почему ты не понимаешь модель безопасности раста: никогда не изучал её, вот и не понимаешь. Как ты можешь говорить о каких-то "иллюзиях", если ты даже не уровне начинающего растомана не знаешь раст, и даже не понимаешь о чём говоришь?

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

Хотел сказать "совершенно верно", но на самом деле нет. 20 лет назад надо было очень исключительную машину, которая смогла бы собрать растовую программу. У заурядной не хватило бы виртуальной памяти. И своп ну так себе решение проблемы -- это не 20 минут на сборку, а несколько часов.

Но вот то, что ты упускаешь из вида: сегодня на дворе 2024. То, что раст там жрёт компилируя -- это мелочи, по сравнению с тем, что ChatGPT и copilot жрут. Компьютер нужен для того, чтобы он впахивал на благо человека, например на благо программиста, и старпёры, которые этого не понимают, и настаивают на том, что вручную набранный байтик чем-то духовнее и чище сгенерированного программно, демонстрируют стандартный тренд скатывания старпёров в маразм ближе к старости.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 25-Янв-24 01:49 
> Ты когда в последний раз открывал учебники по Computer Science? Когда в последний раз интересовался теорией того, как можно добиваться от программы предсказуемого поведения? Когда в последний раз интересовался тем, как эта теория в практику претворяется?

НИ-КО-Г-ДА!
Меня интересовало всегда как сделать так чтобы программа делала то что мне нужно.
Одно время я заморачивался чтобы она собиралась в минимальный размер.
Хотите теоритизировать - не путайтесь под ногами, делайте это в своём загончике сколько хотите, вам слова плохого никто не скажет.


> Это давно уже не проблема, потому что интерпретаторы остались в прошлом, нонче байткоды и jit, aot, и тому подобные штуки. И языков на выбор -- python, go, C#, Java, Kotlin, ...

Нет, нонче 8+ ядер, 32+гб а всё тормозит так же как на втором пне 20+ лет назад.


> C'шные программы собираются везде, только после того, как ты прошёлся и напихал ifdef'ов больше, чем осмысленного кода, под каждую платформу по сотне ifdef'ов.

Это сильно зависит от того что делает код.
Какойнить nginx не сильно то обложен ifdef для разных аппаратных платформ.


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

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


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

Я за 20+ лет какого кода только не понаписал и чего только не понавылавливал :)
То что вы описали далеко не самый трудный случай.


> но на KISS кладёт болт. И в C++ с этим хуже, поскольку там гораздо проще наворотить сложностей.

Так растоманы тоже на КИСС забили и идут в догонку к крестовикам.


> Если для тебя заверения раста о безопасности, то это значит, что ты их не понимаешь. Раст позволяет инкапсулировать инварианты (чтобы ровно в одном модуле о них думать), и задать ограничения на использование API крейта, которые будут проверяться борроу-чекером. Это всё, что в расте есть для безопасности, и это то, что реально работает.

Дорогой друг, когда я слышу слово "безопасность" то я чётко понимаю что сейчас меня будут пытатся одурачить.
Если вы думаете что безопасность раста чем то нужнее, важнее и ещё как то отличается от безопасности детей в РФ в интернете провозглашённой в 2012 году, или безопасности возникающей при запрете огнестрельного оружия или ещё какой то безопасности - то вы ещё мало этой самой безопасности вкусили. Последняя безопасность которой я не хотел была про намордники.
Я вам так скажу, я лучше буду жить в опасном мире с опасными вещами, с огнестрельным оружием, с опасным интернетом и прочим.
Только вот контуженные вечно приходят и назязывают мне безопасность: то интернет надо отключить, то оружие сдать, то намордник одеть, теперь вот в компах мне зачем то надо всё на абракадабру переписывать и сутками ждать пока все проверки пройдут и оно запустится.

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


> А несъедобность синтаксиса, объясняет нам, почему ты не понимаешь модель безопасности раста: никогда не изучал её, вот и не понимаешь.

Тут всё просто.
Я не хочу писать на расте от слова совсем.
А ещё я не хочу писать на перле, питоне, го, пхп, джаве и сотнях других языков.
Но когда мне приходится это делать то даже петон вполне себе пишется, а гниль - нет.
Если язык создавали фонатики для фонатиков (типа браинфака) - удачи вам.


> сегодня на дворе 2024. То, что раст там жрёт компилируя -- это мелочи, по сравнению с тем, что ChatGPT и copilot жрут.

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


> старпёры, которые этого не понимают, и настаивают на том, что вручную набранный байтик

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 11:27 
> Меня интересовало всегда как сделать так чтобы программа делала то что мне нужно.

А, типичный ремесленник-самодельщик. Не, это тоже хорошо, никого даже не пытаюсь обидеть, но просто многое объясняет.

> Нет, нонче 8+ ядер, 32+гб а всё тормозит так же как на втором пне 20+ лет назад.

Мне кажется кто-то просто забыл КАК оно тормозило на втором пне 20+ лет назад.

> Какойнить nginx не сильно то обложен ifdef для разных аппаратных платформ.

Разумеется. Потому что он не сильно и взаимодействует с аппаратной частью.

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

Это и называется бедностью и невыразительностью синтаксиса.

> Только вот контуженные вечно приходят и назязывают мне безопасность: то интернет надо отключить, то оружие сдать, то намордник одеть, теперь вот в компах мне зачем то надо всё на абракадабру переписывать и сутками ждать пока все проверки пройдут и оно запустится.

О, так ты еще антиковидчик))) Это ооочень многое объясняет!

> и сутками ждать пока все проверки

Всем пофиг что у тебя комп с помойки. Твое мнение никого не интересует.
Делай форк и поддерживай старый код.

> И мне не нравится что эта гниль пролезает в проекты и мне приходится тратить своё время и на их поддержку и на их сборку.

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

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

Опять же, на твое личное мнение всем как-то положить.

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

Старпёры, которые вам собирают линукс как раз добавляют раст, ну или как минимум не против этого.
Пока что пованивают пара маргиналов, которые вот лично мне не собрали ни байта.

Цифры в нике конечно не показатель, но такое ощущение, что там должно быть 73 или даже 63.
Потому что... субъект, которого всё устраивает, ничему учиться не хочет, хочет чтобы все было как есть, древний комп, который даже раст не тянет (у меня на одном компе растософт собирается на интуле 2500, помните такой?, и собирается достаточно шустро, поэтому сложно представить что за древность у вас), банкингом не пользуется.
В общем если подвести итоги... suck to be you, больше добавить нечего.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 25-Янв-24 21:37 
> А, типичный ремесленник-самодельщик. Не, это тоже хорошо, никого даже не пытаюсь обидеть, но просто многое объясняет.

А вас не смущает что я ориентирован на конечный результат а вы на процесс?


> Мне кажется кто-то просто забыл КАК оно тормозило на втором пне 20+ лет назад.

Нет, я помню как всё ускоприлось когда пень2 266 поменялся на пень3 1333.


> Это и называется бедностью и невыразительностью синтаксиса.

Вы жалуетесь что в алфавите мало буков?)
Тут как говорится плохому пограмисту и язык вечно не торт :)


> О, так ты еще антиковидчик)))

Нет, я за свободу, даже если свобода сдохнуть.
Мне где то в марте уже стало понятно что это лажа рускрученная СМИ, когда в италии никто замертво не падал на улице как в кетайских роликах.


> Всем пофиг что у тебя комп с помойки. Твое мнение никого не интересует.

Вы с этим заявлением приходите хотя бы лет через 10, пока что 5950х + 128гб ецц не тянет на помойку.
А моё мнение - так я меинтейнер кое чего, так что если моё мнение не важно, то ищите себе других меинтейнеров. Только вряд ли у них условия и как результат мнение будут отличатся.
А потом у таких какакодеров окажется что их мегапроект ни в одном дистре не представлен.


> Как же ты их поддерживать будешь, если ты в раст ни в зуб ногой?))

А никак не буду.
Сношайтесь вы с этим сами.
Я пойду писать своё.
В общем это мой ответ Home Assistant во много из за ихнего маразма с кучей петонячих модулей и многочисленных проблем с пикрипто который теперь с гнилью.


> Опять же, на твое личное мнение всем как-то положить.

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


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

Дорогой дружок, в жизни есть масса не решённых проблем, и переход с С на гниль не решает ни одной из них для меня лично, и даже наоборот создаёт их.
Последние полтора года я был занят релокацией себя и семьи, от компов/телефонов/планшетов мне нужно было ровно одно: чтобы они работали а не чтобы я тратил своё время на поддержку их работоспособности.
Сейчас интерес сместился в сторону получения денег, и опять же тратить время на гниль - это тратить время с отрицательным результатом.
Есть ещё тема с умным домом, где гниль опять же только мешается ибо только добавляет проблем усложняя поддержку Home Assistant.

Гниль - это 99% усилий для решения 5% проблем.
Как только вы перестанете заморачиватся процессом и начнёте думать за результат (который не в том чтобы не было уязвимостей) то всё поймёте.


> банкингом не пользуется.

Не знаю как вы, но у меня был "ВИП" банкинг и в РФ и теперь тут тоже. Свой персональный манагер, доступ к управлению счетами через инет. В РФ я это делал через браузер, тут через приложение.
Я уже встречался с местным аналогом грефа и местными пилильщиками банковского приложения чтобы пофиксить то что у меня в нём не работало. И переодически шлю пожелания (багрепорты) разрабам и их начальству с тем что не так.
Потому не пытайтесь смешить меня словами про банкинг, ибо вы жрёте что дают и даже посолить попросить не можете.
Но банкинг нынче не торт - он для мало обеспеченных с депозитами до 10к бачей, надо валить в крипту, если деньги есть.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено n00by , 26-Янв-24 08:03 
>> Ты когда в последний раз открывал учебники по Computer Science? Когда в последний раз интересовался теорией того, как можно добиваться от программы предсказуемого поведения? Когда в последний раз интересовался тем, как эта теория в практику претворяется?
> НИ-КО-Г-ДА!

А вот и напрасно. Теория -- любопытная штука. :)

Фишка в том, что доказательство корректности тривиально, когда программа состоит из чистых функций. Чистая - это когда не хранится состояние и нет побочного эффекта. А побочный эффект - это и есть результат, ради которого мы запускаем программу. :)

На практике Haskell -- очень хороший язык, но он слишком ленив и потому написано мало. Rust - внешне похож на функциональный (нет императивного return), но если об этом заговорить с любителями языка, выясняется, что они боятся повторить судьбу Хаскеля.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 09:31 
>синтаксис понятен любому идиоту

ага особенно с void (*functionPtr)(void);
и всякие && || ^ & | << >>


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Совершенно другой аноним , 25-Янв-24 10:42 
Но согласитесь, у Rust с этим гораздо хуже..

fn longest<'a, 'b : 'a>(x: &'a String, y: &'b String) -> &'a String {
...
}

Почему-то сразу вспоминается Говард Лавкрафт с его "Пх'нглуи мглв'нафх Ктулху Р'льех вгах'нагл фхтагн".


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 11:56 
Добавился символ ', выкинули символ ^.
Не вижу ничего сложного - очень похоже int (^)(char, float)
К такому привыкаешь за примерно недельку ленивого программинга на раст по вечерам.

В си тоже хватает такого
#define container_of(ptr, type, member) ({                      \
        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
        (type *)( (char *)__mptr - offsetof(type,member) );})


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Совершенно другой аноним , 25-Янв-24 12:20 
> Добавился символ ', выкинули символ ^.
> Не вижу ничего сложного - очень похоже int (^)(char, float)

не скажите. Когда два подряд спец-символа, как-то глаз спотыкается и выглядит не очень как по мне. А так-то да - ко всему можно привыкнуть и на Brainfuck-е писать, если сильно прижмёт.

> В си тоже хватает такого
> #define container_of(ptr, type, member) ({                      \
>        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
>        (type *)( (char *)__mptr - offsetof(type,member) );})

В Вашем примере как-раз такого и нет, но есть обилие скобок.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено n00by , 25-Янв-24 16:39 
> Когда два подряд спец-символа, как-то глаз спотыкается и выглядит не
> очень как по мне.

Это про одинарную кавычку? Она ж во многих языках требует закрывающей пары. Потому и не читается.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Ivan_83 , 25-Янв-24 21:04 
Таких макросов полторы штуки и нужны они крайне редко, если именно по нужде а не потому что ты пишешь "криптокод" ибо думаешь так же странно.

Указанный вами макрос и даже typeof() я не использовал вообще никогда - не было необходимости.
Самое извращенское было:

#ifndef offsetof /* offsetof struct field */
#    define offsetof(__type, __field)                \
        ((size_t)((const volatile void*)&((__type*)0)->__field))
#endif

#define MEMCPY_STRUCT_FIELD(__dst, __sdata, __stype, __sfield)        \
    memcpy((__dst),                            \
        (((const char*)(__sdata)) + offsetof(__stype, __sfield)),    \
        fieldsetof(__stype, __sfield))

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Bottle , 25-Янв-24 11:01 
>Фишка программ на С в том что они быстро и везде собираются

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 18:40 
Растоманам лучше помалкивать о скорости сборки, а то выйдет неудобно :)

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено RM , 24-Янв-24 19:29 
Вот кстати почитать про palloc было занимательно, я например не знал что оно и зачем надо

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Серб , 24-Янв-24 12:35 
Забавный патч. Просто удаляет реалокацию? Она там вообще не нужна была?

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено пох. , 24-Янв-24 12:41 
конкретно в этом месте она была очевидно вообще мимо тазика.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 15:14 
О, пох, здоровеньки булы!
Долго жить будете, однако!
Крайний раз, когда доводилось общаться, Вы помирать уж собирались.
А я и говорил, что в поряде будете.
За это время я сам чуть ласты не склеил и потерял все мирское.
В общем рад, что с Вами ок.

В целом всех рад видеть, особенно полтора анончика, конечно же! Мир вам, пацаны.

Что вообще нонче в мире ит происходит?
Пингвин еще не лопнул от жЫра?
Нуби залечил свою боль?
Михаэль уже вывел отечественные ОС в лидеры рынка БРИКС?


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 15:50 
О, вижу некие инновации. А говорили бот-модератор, ии, вот это все...а за ширмой как всегда Васян.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено n00by , 24-Янв-24 17:10 
shrink - это урезать буфер. "Преждевременная оптимизация - корень всех зол."

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 02:45 
> Преждевременная

Сколько десятилетий этому коду? Это по человеческим меркам уже глубокий пенсионер, а вы размышляете отдавать ли его в детский садик или рановато ещё...


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено n00by , 25-Янв-24 10:31 
> вы размышляете отдавать ли его в детский садик или рановато ещё...

Читаете мои мысли? Доктор в курсе?


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:54 
>возникающих при использовании утилиты split для разделения данных, передаваемых при помощи QR-кодов

Баш-скрипты надо запретить. Использовали бы питон - такой проблемы бы не было. Это им ещё повезло, если на выполнение данных, переданных в коде, как команды шелла не нарвались.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 13:59 
> Баш-скрипты надо запретить.

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

Питон (по крайней мере, классический cpython) в этом плане не сильно лучше.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 02:43 
> Одна из ключевых проблем баша — то, что он позволяет запускать программы, которые были написаны на сишке.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 14:47 
Ну ещё бы shell не позволял запускать исполняемые ELF-файлы. Толку тогда от него.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 15:37 
Питон позволяет отлично и удобно запускать исполняемые файлы. amoffat/sh. Но что намного важнее, он обладает нормальной типизацией, нормальными функциями, нормальной системой модулей, нормальной стандартной библиотекой и нормальным синтаксисом, и поэтому там не приходится извращаться с запуском чужих бинарей, что кстати ещё и медленно, с взаимодействием с ними через извращённые интерфейсы, зачастую in-band, что приводит к хрупкости и атакам. Кто использует баш вместо питона для чего-либо сложнее find . -exec echo hello {} \; - того вон из профессии.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 15:41 
Унас есть такая пословица

>you are only as good, as your tools.

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


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 16:05 
Желание везде пихать любимый яп вместо баша тоже детектор отклонений кстати.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:54 
Баш это клей для конвейеров. Если вы используете что-то большее, чем вызовы и циклы - скорей всего вы выбрали баш неправильно.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено User , 24-Янв-24 15:58 
Фигня в том, что (Парадоксально, да?) bash - язык существенно более "высокоуровневый", нежели python. Т.е. заменить одно на другое кнешн можно - но писать придется прям существенно больше с понятными последствиями по качеству писева.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:10 
> писать придется прям существенно больше

И вот тут бы примеры привести, но нет, User не смог для этого встать с дивана.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено User , 24-Янв-24 21:26 
>> писать придется прям существенно больше
> И вот тут бы примеры привести, но нет, User не смог для
> этого встать с дивана.

Ээээм... возьмите любой однострочник на баше (Ну хоть один-то видеть должны были, да?), чтоли - и попробуйте его в python-скрипт преобразовать. Фиг с ним с бойлерплейтом (Хотя его тоже больше) - таки ж ведь и кода больше придется писать.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 01:14 
Ты неправ, баш приспособлен под определённые задачи куда лучше любых альтернатив. И да, кода меньше. Как мне видится, основное его ограничение в том, что всё, по-сути, строки, и нет возможности эффективно оперировать байтовыми последовательностями (в частности, больше всего не хватает IFS=\0 или чего-нибудь вроде того). К 45 годам нагромождений легаси и ограничений можно привыкнуть, к невозможности работать с произвольными именами файлов без find -- нет.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено User , 25-Янв-24 08:11 
> Ты неправ, баш приспособлен под определённые задачи куда лучше любых альтернатив. И
> да, кода меньше.

В том плане, что не "более высокоуровневый", а "фактически DSL"?

>Как мне видится, основное его ограничение в том,
> что всё, по-сути, строки, и нет возможности эффективно оперировать байтовыми последовательностями
> (в частности, больше всего не хватает IFS=\0 или чего-нибудь вроде того).
> К 45 годам нагромождений легаси и ограничений можно привыкнуть, к невозможности
> работать с произвольными именами файлов без find -- нет.

В тикле кстати все тоже строки - и в общем-то норм. А за шеллом, построенным на принципах моложе поздних 70х\ранних 80х - вам пожалуй что в microsoft :). Xonsh\ipython все же сиииильно не дотягивают - те же яйца, вид в профиль.


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 02:40 
Проблема с башем та же, что и с Перлом - сплошной write-only код получается, наполовину состоящий из спецсимволов. Конечно очень сжато получается, только этот код через год сам автор не разберёт.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено User , 25-Янв-24 07:12 
> Проблема с башем та же, что и с Перлом - сплошной write-only
> код получается, наполовину состоящий из спецсимволов. Конечно очень сжато получается,
> только этот код через год сам автор не разберёт.

Так никто не говорит, что это "хороший" язык. Просто - "более высокоуровневый".


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 27-Янв-24 01:02 
Использовать надо Nushell, а не Питон.  Питон - как и любой язык не имеющий удобной интеграции с командной строкой - плохо подходит под скриптование.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 17:41 
А в чем уязвимость? Переполнения отлавливаются железом и программа завершается

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:21 
Как повезёт. Если переполнение выйдет за границу страницы памяти, то отловится.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:08 
Никогда такого не было, и вот опять: ненастоящие сишники прокрались в GNU и накодили там CVE.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:24 
"Ненастоящие" и в GNU пробрались. И в GNU были наезжавшие на Столмана.

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:29 
А как нонче трушность проверяют?
По ухоженности бороды?
Длине штаников?
Выбору туалетной комнаты м,жо,оно?!
Или это не взаимоисключающие параграфы?

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 24-Янв-24 19:26 
Вот бсдишечка от гнутого софта и избавляется потихоньку.
#все правильно делают! Бсди чмафки и любимки111!

"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено Аноним , 25-Янв-24 02:37 
> при замене вызова функции xrealloc на xpalloc

Угу, типа починили, до следующего раза. А вот писали бы на современном C++  - не пришлось бы заниматься мартышкиным трудом по ручному управлению памятью..


"Уязвимость в утилите GNU split, приводящая к переполнению бу..."
Отправлено _ , 26-Янв-24 00:02 
Не надо полумер! Переписывайте на ржавом! :)