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

"Уязвимость в утилите 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
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+4 +/–
Сообщение от Аноним (1), 24-Янв-24, 10:18
То ли ещё будет когда split научат с Unicode работать, точно наступят на все возможные грабли, как наступили в sort. Сейчас split только байтовые счётчики поддерживает и корежит при разделении текст в многобайтовых кодировках.
Ответить | Правка | Наверх | Cообщить модератору

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

	79. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (1), 24-Янв-24, 15:27
	> А что с sort не так? https://bugzilla.suse.com/show_bug.cgi?id=928749
	Ответить | Правка | Наверх | Cообщить модератору

	178. "Уязвимость в утилите 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; Учитывая что весь патч - это не переделка, а просто выкидывание какого-то ненужного гомна без которого работает даже лучше, это и граблями называть едва ли корректно В итоге окажется что какой-то очередной эксперимент по впиливанию незаметных дыр в попенсорс Или - откровенная криворукость и отсутствие внятного тестирования
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

2. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–6 +/–
Сообщение от cheburnator9000 (ok), 24-Янв-24, 10:26
Срочно переписать на rust.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+3 +/–
	Сообщение от НяшМяш (ok), 24-Янв-24, 10:39
	Уже: https://uutils.github.io/coreutils/book/utils/split.html
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Аноним (7), 24-Янв-24, 10:47
	v0.0.24 что именно тут уже ?
	Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–1 +/–
	Сообщение от Аноним (26), 24-Янв-24, 12:08
	> v0.0.24 > что именно тут уже ? Уже в версии v0.0.24 дыреней меньше, чем в coreutils 7.2.
	Ответить | Правка | Наверх | Cообщить модератору

	27. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (7), 24-Янв-24, 12:16
	как вы это определили ?
	Ответить | Правка | Наверх | Cообщить модератору

	120. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 24-Янв-24, 18:06
	По размеру, очевидно же. Просто умалчивают о маленьких дырочках, более приятных в использовании.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (91), 24-Янв-24, 16:44
	Пользуюсь полгода, всё отлично работает
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	96. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+4 +/–
	Сообщение от Аноним (7), 24-Янв-24, 17:02
	я пользуюсь оригинальной coreutils и представьте тоже всё отлично работает
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (106), 24-Янв-24, 17:49
	Так на здоровье, рад за вас.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Янв-24, 16:21
	Готов поспорить ты этим не пользуешься
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	93. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Аноним (91), 24-Янв-24, 16:44
	Ну я пользуюсь, задавай вопросы.
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (66), 24-Янв-24, 14:41
	>Срочно переписать на rust. Не дождёдесь. Эти скорее на Guile перепишут.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	87. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (-), 24-Янв-24, 16:17
	Мы перепишем на любом языке, который имеет одобрение Столлмана и имеет строгую, непримиримую по отношению к проприетарщикам и пермиссивщикам, лицензию.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (106), 24-Янв-24, 17:51
	Guile, common lisp. Вперёд. Это не должно быть очень сложно)
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (128), 24-Янв-24, 19:03
	На CL такое действительно пишется за вечер, с тестами и документацией.
	Ответить | Правка | Наверх | Cообщить модератору

	130. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (7), 24-Янв-24, 19:08
	не рассказывайте им )))
	Ответить | Правка | Наверх | Cообщить модератору

	146. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (146), 24-Янв-24, 21:47
	Ну собственно я знаю. Но обычно те кто "лишь бы батька одобрил фар фап" умеют писать только на матерном русском.
	Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

	125. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (125), 24-Янв-24, 18:48
	Забавно, но у Guile, несмотря на то что это "гнушный" язык , лицензция как раз таки совместимая с проприетарщиной и пермессивщиной. И ментейнеры его, насколько я знаю, со Столлманом не особо дружат.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

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

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

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

	113. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Вы забыли заполнить поле Name (?), 24-Янв-24, 17:56
	>>Срочно переписать на rust. > Не дождёдесь. Эти скорее на Guile перепишут. Как будто это плохо.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

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

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

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

	20. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+2 +/–
	Сообщение от Аноним (20), 24-Янв-24, 11:38
	> а сишка - это же вообще технология без всякой защиты то что надо для написания ядер ОС и драйвер. А всякие умные указатели и прочие RAII - это всё для прикладухи, а не для системщины.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+2 +/–
	Сообщение от Аноним (22), 24-Янв-24, 11:41
	> то что надо для написания ядер ОС и драйвер. Да, именно то что нужно! Чтобы дырень в твоем драйвере, написанном лучшими погромистами из имеющихся, рутанула тебе всю ОСь))
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (20), 24-Янв-24, 12:01
	ОЙ, да не завидуй ты так. Ты ни на каком языке никакого драйвера не напишет, даже на самом безопасном.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Аноним (53), 24-Янв-24, 13:55
	Лучше тот, кто не пишет драйверов, чем тот, кто пишет их на сишке. Первый хотя бы не делает хуже.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+6 +/–
	Сообщение от Аноним (20), 24-Янв-24, 17:02
	Ты получается круче всех инженеров в IBM/RedHat. Я горжусь, что живу в одно время с такими людьми и имею возможность с ними на форуме общаться.
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (106), 24-Янв-24, 18:01
	Он прав. Ядра ОС это пожалуй единственная ниша для сишки. Драйверы - нет.
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

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

	137. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от stalinus (?), 24-Янв-24, 19:32
	Всё верно, но зря ты так подробно расписал. Анонимы opennet читают первые десять слов, а дальше у них происходит переполнение буфера со стиранием уже прочитанного.
	Ответить | Правка | Наверх | Cообщить модератору

	150. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (-), 24-Янв-24, 23:20
	> "дальше у них происходит переполнение буфера со стиранием уже прочитанного" Они что тоже на СИ написаны? Вот это откровение! Но тогда понятно почему некоторые настолько дырявые)
	Ответить | Правка | Наверх | Cообщить модератору

	170. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от berium (?), 25-Янв-24, 05:30
	Переполнение буфера реализуется в коде на любом языке программирования, даже Rust от этого не спасёт.
	Ответить | Правка | Наверх | Cообщить модератору

	158. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (158), 24-Янв-24, 23:51
	Тебе про Фому, а ты про сисколы. Да еще и человека соблазнил тебе чаю подлить.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	28. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+5 +/–
	Сообщение от Аноним (-), 24-Янв-24, 12:16
	А сишники забавные ребята. Каждый раз когда ты начинаешь их мордочкой тыкать в их... эээ... код, они начинают верещать про раст, про его проблемы, то что он не серебрянная пуля и тд. Мы тут не раст обсуждаем, да и кроме него есть еще другие языки. Скажите уже что-то дельно в оправдание дыряшки. А пока что мозги не включают сишники. PS. хруст первым приплел ты))
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	171. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–1 +/–
	Сообщение от berium (?), 25-Янв-24, 05:39
	Нет разницы кто и кого первым приплёл. Когда кодовая база на языке "ВАШЕНАЗВАНИЕ" достигнет объёмов кодовой базе на C/C++, тогда можно будет сделать какие-то выводы. В будущем Rust займет какую-то нишу, но она будет существенно ниже C/C++, т.к. в последние года произошло размытие проектов по разным языкам программирования, а не как в 80/90-ых выбор между пятеркой языков, из которых два лидировали с колоссальным отрывом.
	Ответить | Правка | Наверх | Cообщить модератору

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

	193. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Совершенно другой аноним (?), 25-Янв-24, 13:06
	>>Нет разницы кто и кого первым приплёл. > разница есть. потому что такая ошибка, как описана (креш на некорректных входных > данных), должна выявляться на этапе тестирования, которого, очевидно нет. и да, > язык программирования тут уже ничего не исправит, просто кодеркам похер на > качество. Тесты у них есть, как минимум с 1993 года. Ошибка была внесена в coreutils 9.2 (2023-03-20). Очевидно, именно эта ситуация не тестируется.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Советский инженер (ok), 25-Янв-24, 18:22
	>Тесты у них есть ага, есть но мягкий ...
	Ответить | Правка | Наверх | Cообщить модератору

	194. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (194), 25-Янв-24, 13:27
	> Сишка - сложный системный язычок, чтобы на нём писать, погроммист должен 150 раз обдумать поведение каждой строчки на выход за пределы, переполнение, нулевые указатели-сегфолт, деление на ноль и т.д. и т.п. т.е. ты не осилил си и так и не научился конструктивно думать, а виноват, очевидно, язык? это язык тебя сюда загнал время на комменты тратить?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

15. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+2 +/–
Сообщение от Аноним (15), 24-Янв-24, 11:23
xrealloc xpalloc... Это какой же должен быть пипец я языке чтобы было столько всяких от alloc от AAalloc до ZZalloc
Ответить | Правка | Наверх | Cообщить модератору

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

	21. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от нах. (?), 24-Янв-24, 11:41
	они в ведре, к сожалению, а не в языке. Продать отдельно от вендыпоганой не получитсо. А в ней и так все хорошо - дай такому альтернативно-одаренному HeapAlloc - он и член сломает, и руки порежет, и код так и не скомпилится даже (так что - безопастно).
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (20), 24-Янв-24, 11:58
	> они в ведре, к сожалению, а не в языке. Да понятно, просто чел возникал изначально, что людям дали malloc(), а им мало, они еще что-то там своё пишут. Плохой язык C, на нем можно свой аллокатор написать, если по какой-либо причине тебя не устраивает тот, который в libc
	Ответить | Правка | Наверх | Cообщить модератору

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

	49. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Аноним (53), 24-Янв-24, 13:49
	Кстати, сколько дыр в этой реализации? Наверное, с десяток.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–3 +/–
	Сообщение от нах. (?), 24-Янв-24, 11:37
	это не в языке, дурашка, это - в головах. В процессоре нет никакого alloc, представляешь - вообще. А проблема именно тем и вызвана что новое альтернативно одаренное поколение полезло теребонькать то что не следовало трогать - затобезопастным способом. Лучше б оно на безопастном язычке, конечно, программировало, тут я с тобой согласен - нет кода, нет опастностей. Но увы, видимо настолько альтернативные, что не смогли освоить даже маркдаун.
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

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

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

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

	51. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+2 +/–
	Сообщение от Аноним (53), 24-Янв-24, 13:53
	Как говорят це-разработчики, "от всех этих дыр нам же только луДше!!1"
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+3 +/–
	Сообщение от Аноним (-), 24-Янв-24, 14:17
	Так правильно говорят! Чем запутанее код и чем больше там непонятных багов - тем меньше шансов, что такого уволят. Но даже если и уворят, то он найдет себе такой же проект написанный через одно место и будет сидеть на его поддержке годами. Ты почитай на чем должны зарабытывать ГНУтики, согластно манифесту коммуняки столмана. Правильно "на поддержке". А чтобы поддержка и денюжка не закончились, то баги тоже не должны заканчиваться.
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (-), 24-Янв-24, 12:48
	> это не в языке, дурашка, это - в головах. Полностью согласен! В головах у сишников, очевидно, опилки. Тк на протяжении 30-40 лет делать одни и те же ошибки... Это надо явно обладать альтрнативным мышлением. К сожалению целое поколение (а то и два) таких альтернативно одаренных сейчас сидит и пишут системы, от которых требуется максимальная надежность. Но хуже того - они противодействуют любым попыткам как-то изменить ситуацию - тк в этом случае все их знания о 193 Undefined Behavior в C99 становятся ненужными и они могут идти работать дворниками.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	50. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (53), 24-Янв-24, 13:51
	> в этом случае все их знания о 193 Undefined Behavior в C99 становятся ненужными А были ли знания? 99% сишников про UB не задумываются. Если программа не падает на его компе и его входных данных, то она считается стабильной.
	Ответить | Правка | Наверх | Cообщить модератору

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

	60. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (-), 24-Янв-24, 14:22
	Отличное описание типи-кал СИ разработки. Сначала зачем "Тратить время на нештатные случаи и маловероятные ситуации", а потом: - у нас хартблид у половины интернета - почти все андроид телефоны оказывают дырявыми - машинки тойоты разгоняются сами по себе и убивают людей Имеено поэтому такой подход должен помереть (вместе с бракоделами)
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (20), 24-Янв-24, 14:33
	> Имеено поэтому такой подход должен помереть (вместе с бракоделами) И кто останутся? Один ты, ничего не написавший?
	Ответить | Правка | Наверх | Cообщить модератору

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

	68. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (-), 24-Янв-24, 14:44
	Свято место пусто не бывает) Как сказал Линус - мы седые и старые, надо готовить молодеж на замену. И добавил раст в ядро. Вот новое поколение и будет писать. > Один ты, ничего не написавший? То что я написал уже 10 лет работает, так что мне есть чем гордиться.
	Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

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

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

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

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

	95. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (75), 24-Янв-24, 17:00
	>Так я горжусь >так что без гордыни Не то чтобы я задроttством каким занимаюсь и к словам придираюсь, но на самом деле вопрос действительно важный. Когда-то тоже много чем гордился. Считал себя нереально вумным, як вутка и вот это все. Но к счастью Господь не оставил и вразумил. Теперь, чтобы я не делал, делаю как для Бога и с пониманием, что сам по себе лишь инструмент в Его руках, реализующий Его волю. Являясь при этом лишь сосудом всякой нечистоты. Лучше не дожидаться жесткого вразумления. Вопрос в отношении и восприятии себя и своего труда. Что основа, а что следствие. Тогда и покой и радость внутренняя будет от результата. Да и в целом. Не путаем эту внутреннюю радость скажем с отжигами лучших блудниц и прочих там няшностей. Это другое.
	Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

	103. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (-), 24-Янв-24, 17:34
	Не, сорри. У меня выдуманные невидимые друзья закончились еще в детстве. Ну т.е в такого бога как описывают я не верю. Особенно видя что в мире происходит (жестокость, насилие и тд). Но, а вот если представить, что он просто злой, создал несовершенных существ, наказал их за несовершенность (которую сам добавил) и теперь наслаждается их страданиями... Вот в такого Бога я бы поверил. Даже в то что некоторых людей он создал по образу и подобию)
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (75), 24-Янв-24, 17:56
	Здесь как Вам будет угодно. Просто из собственного опыта рекомендовал. Недавно узнал, что и друзей кроме Бога то нет. все имеют свою цену. Кто в денежном эквиваленте а кто и в иных единицах. Догматическое представление Вы обрисовали неверно. Но в эти дискурсы вдаваться тут не будем. Просто почитайте, при случае источники. Ну а в целом почему завел разговор, когда у человека мир в душе, ему нет нужды хвалиться и/или гордиться чем-либо. Извините, если чем задел, не хотел.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Серб (ok), 24-Янв-24, 15:23
	> Как сказал Линус - мы седые и старые, надо готовить молодеж на замену. > И добавил раст в ядро. > Вот новое поколение и будет писать. Только вряд ли на rust. Это хороший способ переманить разработчиков. Потыкаются. Замучаются с поддержкой множества архитектур и вариантов конфигурации ядра и: 1) или сделают rust нормальным языком (что вряд ли, тяжко существующие решения с необходимыми требованиями связать) 2) или начнут использовать существующие наработки в ядре.
	Ответить | Правка | К родителю #68 | Наверх | Cообщить модератору

	56. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–1 +/–
	Сообщение от нах. (?), 24-Янв-24, 13:58
	> К сожалению целое поколение (а то и два) таких альтернативно одаренных сейчас сидит и пишут системы ну так ты-то ничего кроме комментов на опеннете не умеешь... а ресдох, написанный "правильным" поколением - почему-то сдох. Что ж ето деется - никому, оказывается, даром не нужна безопастная ось? Попробуй приплачивать? > Но хуже того - они противодействуют любым попыткам как-то изменить ситуацию потому что пока что попытки сводятся к "давайте заставим их писать как НАМ хочется". От тех кто не умеет ничего кроме coc.md и мертворожденных переписываний того что в переписывании не нуждалось.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	63. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Аноним (-), 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 То приходим к неутешимому выводу - для успешности проекта оно необходимо. Ну чтобы затыкать рот всякому невоспитанному б-лу.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Ivan_83 (ok), 24-Янв-24, 16:20
	Я вам повторю, поскольку до вас никак не доходит. 30 лет назад была куча безопасных языков, и 20 лет назад тоже. Я обожал Visual Basic, целиком и полностью супер язык, супер IDE, супер справка. Была только одна проблема: или ты пишешь на С или оно работает медленно и весит много. А проги тогда распространялись дискетами. Иногда тяжёлые вычисления выносили в DLL на С а гуй оставляли на чём то более высокоуровневом. Этот ваш раст в те времена даже скомпелячить нельзя было, ресурсов бы не хватило. И пользоватся им тоже было бы не возможно - он дико тормозной, ждать пока он соберёт хелло ворлд за 20 минут никто бы не стал. Вся безопасность раста свелась бы к тому, что код написанный на нём даже не собрался а если и собрался то не запустился :) И сейчас, не смотря на все кудахтанья, успехи раста сводятся к порче отдельных С/С++ проектов, которые теперь и собирать трудно и поддерживать не возможно из за смешения языков. Всё что делают растоманы - это греют воздух и сжирают производительность. Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке. В плане поддержки это полная абракадабра. Фишка программ на С в том что они быстро и везде собираются, синтаксис понятен любому идиоту, и ошибки относительно легко исправляются, особенно современными инструментами. У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Советский инженер (ok), 24-Янв-24, 16:58
	>синтаксис понятен любому идиоту время идиотов в кодинге прошло >ошибки относительно легко исправляются, особенно современными инструментами все упоротые сишники все время рассказывают про эти современные инструменты, но элементарного fuzz testing так и не осилили на таком важном проекте !!! так что ты, прежде чем учить жизни растоманов, научись этими современными инструментами пользоваться, а не в коментах про них рассказывать.
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Ivan_83 (ok), 24-Янв-24, 20:18
	> время идиотов в кодинге прошло О нет, как раз новое поколение пришло :) Просто когда мы бунтовали то переписывали библиотеки и проекты с нуля, а теперь мода переписывать на модных языках. > все упоротые сишники все время рассказывают про эти современные инструменты, но элементарного fuzz testing так и не осилили на таком важном проекте !!! Это ваша оценка. Моя оценка отличается: я не боюсь ошибок в программах и то что программы падают. Там где критично - пусть производитель делает +1 резервирование, остальное перезагрузят/перезапустят пользователи.
	Ответить | Правка | Наверх | Cообщить модератору

	151. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (-), 24-Янв-24, 23:23
	Предположим, пользователи перезапустят. А что делать с уязвимостями типа heartbleed? Когда в один момент выясняется, что половина шифорвания была уязвима? Не думаю, что вы бы обрадовались "о, прочитать мою почту, майору, провайдеру и вообще кому угодно стало проще". Или например удаленноен получение рута через уязвимость браузера, хорг сервера и тд. Мне было бы неприятно, если бы по моему компу шарился кто попало.
	Ответить | Правка | Наверх | Cообщить модератору

	162. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Ivan_83 (ok), 25-Янв-24, 01:09
	Ничего, всё исправят в своё время, как обычно. > Не думаю, что вы бы обрадовались "о, прочитать мою почту, майору, провайдеру и вообще кому угодно стало проще". Прежде всего вы должны признатся самому себе что: - вы пока никому нафиг не нужны - вы переносите свои страхи касающиеся реального мира на компьютерный мирок где вы типа чтото с ними можете сделать - и вашу почту таки читают, потому что скорее всего она хостится не у вас дома, и ваши респонденты тоже пишут вам с ящиков которые хостятся не у вас дома > Или например удаленноен получение рута через уязвимость браузера, хорг сервера и тд. И что? Перезагрузить, переустановить. Всё как обычно.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (-), 24-Янв-24, 17:10
	Вот вроде говорите правильные вещи, но выводы из них делаете... мама родная... Да 30 лет назад сишка захватила мир, потому что можно было быстро наыдлокодить программу. Уже тогда была ада, но просто на ней писать было сложнее, а идиотов оказалось больше. Да 20 лет назад не было таких мощностей как сейчас. Ну и проекты были маленькие - сравните ядро тогда и сейчас. Именно потому что сейчас это всё есть - то нужно переложить все возможные проверки на компилятор! Пусть лучше проц битики перекладывает, раз программер уже не в состоянии уследить за всем. Сишники не в состоянии следить за памятью в больших проектах. Да в общем-то никто не в состоянии, просто только сишники упорно пытаются доказать всем, что именно они могут и как всегда жиденько... Они обязательно где-то накосячат, хотя правила до тупости просты: - один раз память выделил - один раз очистил, не больше и не меньше - за пределами выделенного не читай - за пределы выделенного не пиши И всё! Просто сложность проекта не позволяет это всё удержать в голове. Эта очередная новость - тому доказательство. > Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке. Невозможно свести ноль в ноль. У си никакого прогресса за 20 лет не было. У плюсов был и довольно большой. Но не у дыряшки. > и ошибки относительно легко исправляются Ошибки нужно не делать, а не сначала делать, а потом легко исправлять. Плюс посмотри по сколько лет эти ошибки живут в проектах. Годами! И их никто не замечает. > У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис. Раст долго собирается как раз потому, что он делает куча проверок в compile-time, в отличие от сишки. Но в рантайме он сравнимо быстр. И это уже не вопрос, это утверждение. А несъедобен синтаксис у него только для закостенелых мозгов.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	143. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–1 +/–
	Сообщение от Ivan_83 (ok), 24-Янв-24, 21:04
	От того что у вас мобила лишний раз перезагрузится или приложение в ней - ничего страшного не случится. Вот и вся цена ошибок. Не надо раздувать из мухи слона. > Невозможно свести ноль в ноль. У си никакого прогресса за 20 лет не было. У плюсов был и довольно большой. Но не у дыряшки. Я вообще то про прогресс вычислительной мощности который раст помножает на ноль. Самому С развиватся особо и не надо, С++ прекрасный пример того как делать нельзя. Но вот раст упорно делает как С++ при этом заявляя себя заменой всему. > Плюс посмотри по сколько лет эти ошибки живут в проектах. Годами! И их никто не замечает. И никому не мешают, так бы нашёлся кто то кто сам починил или заплатил. > А несъедобен синтаксис у него только для закостенелых мозгов. Есть множество примеров с обычными языками и письменностями. Раст это азиатские иероглифы, против С - простого и лаконичного как английский.
	Ответить | Правка | Наверх | Cообщить модератору

	155. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (-), 24-Янв-24, 23:26
	У вас через браузер, через вьювер картинок или через пдф-просмоторщик уведут пароли, взломают банкинг, взломают сервак через специально оформленный пакет. Вот и вся цена ошибок))) > Я вообще то про прогресс вычислительной мощности который раст помножает на ноль. Еще раз. Это не соответствует действительности. У раста медленней только компиляция. Скорость выполнения сравнима с си, где-то даже быстрее, где компилятор смог оптимизировать лучше. Вы компилируете один раз и софт выполняется сотнями тысяч экземпляров скачав нужный пакет. Поэтому скорость компиляции на предпоследнем месте по приоритетам. Несколько землекопов, которым ну вот все хочется компилировать самим - никого не интересуют. > Самому С развиватся особо и не надо Ну-ну. А когда в си появятся... напр. нормальные enum, а не убогая обертка над числом? Или associated value? Или это излишество, типа деды и без них прожили и нам не нужно? Вообще, тот кто не развивается, то в итоге вымирает. > Раст это азиатские иероглифы, против С - простого и лаконичного как английский. Уверен на 95% что вы или ничего не писали на расте, или писали какой-то hello world. > простого и лаконичного как английский Простите, но это сравнение просто смешно)) Да, английский может проще чем иероглифы, но простым и лаконичным его уж точно назвать нельзя. Местами он существенно сложнее, чем напр. японский.
	Ответить | Правка | Наверх | Cообщить модератору

	164. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Ivan_83 (ok), 25-Янв-24, 01:18
	> У вас через браузер, через вьювер картинок или через пдф-просмоторщик уведут пароли, взломают банкинг, взломают сервак через специально оформленный пакет. Мой банковский счёт не стоит таких усилий, будем честны, и ваш тоже :) > Скорость выполнения сравнима с си, где-то даже быстрее, где компилятор смог оптимизировать лучше. Да да, и все владения объектами, все синхронизации доступа они тоже бесплатные. > Несколько землекопов, которым ну вот все хочется компилировать самим - никого не интересуют. Так вы щас топите против опенсорца, потому что возможность самостоятельно собрать один из основных критериев свободы. А гниль настолько тормозная что ещё немного и сборка будет проходить только у бигкорпов на топ500 компах. > А когда в си появятся... напр. нормальные enum, а не убогая обертка над числом? Или associated value? Зачем? Если вам нужен сахар - используйте другие языки, С для минималистов. > Вообще, тот кто не развивается, то в итоге вымирает. Расскажите это обилию растительности и живности вокруг вас. Есть масса замечательных стабильных форм, которые лишь незначитально видоизменяются со временем для адаптации к изменениям окружающей среды. Если бы всё в природе развивалось как кресты или гниль то осталось бы полтора огромных мутанта размером с материк. В общем можете посмотреть на азиатские иероглифы чтобы понять куда вы идёте, там тоже на любой чих свой иероглиф, они обмазались синтаксическим сахаром почти на 100%.
	Ответить | Правка | Наверх | Cообщить модератору

	183. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (-), 25-Янв-24, 11:04
	> Мой банковский счёт не стоит таких усилий, будем честны, и ваш тоже :) Согласился бы, если бы усилия вообще были нужны. Эксплойт может работать в автоматическом режиме, и ему будт пофиг у вас на карточке 100 рублей или 100 тысяч. > Так вы щас топите против опенсорца, потому что возможность самостоятельно собрать один из основных критериев свободы. Те критерии свободы от поехавших комми и чуваков, которые пытались копирайтить само слово опенсорс, я не признаю. Для меня open source это один критерий - код открытый. Но даже так "свободу собрать у себя" никто не забрал. Подумаешь какой-то гентушник попердолится на час больше. > Если вам нужен сахар - используйте другие языки, С для минималистов. Так пусть минималисты пишут свое ядро только на СИ, а мы будем писать свое ядро на СИ  и Rust. Раз вы такие крутые то сделать форк и поддерживать самим вы точно справитесь) > Расскажите это обилию растительности и живности вокруг вас. Именно поэтому появился Раст, тк если бы вокруг был только СИ - это было бы очень глючно и печально, прям как сейчас. А поп поводу сахара - на него жалуются только неосиляторы, которые больше 10 значков в голове держать не могут. Отсюда и постоянные уязвимости в СИ коде.
	Ответить | Правка | Наверх | Cообщить модератору

	199. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Ivan_83 (ok), 25-Янв-24, 20:53
	> Эксплойт может работать в автоматическом режиме, и ему будт пофиг у вас на карточке 100 рублей или 100 тысяч. Это так не работает в банками, только щиткойнами. Там нужна цепочка чтобы по быстрому перевести и вывести в нал, ради 100 руб никто возится не будет. И у меня банки вечно требуют СМС при любом переводе за пределы своих счетов в одном банке. > Но даже так "свободу собрать у себя" никто не забрал. Подумаешь какой-то гентушник попердолится на час больше. Вы так договоритесь что вам тоже чтонибудь IRL отрежут до уровня невыносимого существования и скажут: нуачо, так же тоже жить можно. Например в бараке без отопления и с удобствами на улице. > Так пусть минималисты пишут свое ядро только на СИ, а мы будем писать свое ядро на СИ  и Rust. Чото вашего ядра нигде не видно, только на чужом паразитируете. > А поп поводу сахара - на него жалуются только неосиляторы, которые больше 10 значков в голове держать не могут. У меня в жизни полно других и проблем и увлечений чтобы забивать голову помоями которые каждый день изобретает очередной фрик. Вы упорно не хотите смотреть вокруг себя и думать, иначе бы давно поняли к чему приходит всё что содержит столько сахара.
	Ответить | Правка | Наверх | Cообщить модератору

	176. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Совершенно другой аноним (?), 25-Янв-24, 09:56
	> Да, английский может проще чем иероглифы, но простым и лаконичным его уж точно назвать нельзя. > Местами он существенно сложнее, чем напр. японский. Прошу прощения, так-сказать на правах лингвиста, боюсь, что японский ни в чём не проще английского. Вот уж где, на самом деле, наркомания во все поля. Насколько я понимаю, даже китайский попроще будет. Для затравки - https://habr.com/ru/articles/673446/. Там ещё есть две части с продолжением, если вдруг станет интересно: https://habr.com/ru/articles/678716/ и https://habr.com/ru/articles/683820/
	Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

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

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

	156. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от жабабыдлокодер (ok), 24-Янв-24, 23:40
	Мобила лишний раз перезагрузится, томограф неправильные данные передаст, искусственная почка зависнет, автопилот на середине маневра отключится. С точки зрения человечества - человечество не заметит, да.
	Ответить | Правка | К родителю #143 | Наверх | Cообщить модератору

	101. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (-), 24-Янв-24, 17:20
	> 30 лет назад была куча безопасных языков, и 20 лет назад тоже. Да они и сейчас есть, Ада например (и особенно Spark Pro). Но, к сожалению, в ядро попала отвратительная дыряшка, которая теперь множит дыряшки для пользователей. > Этот ваш раст в те времена даже скомпелячить нельзя было, ресурсов бы не хватило. А знаешь, раньше люди на телегах ездили и особо не жужжали. Так что и сейчас нужно на бричке на рынок ехать? Или все-таки сесть на автобус? Можно и на улицу в кустики бегать, но люди предпочитают нормальный санузел. Можно > И сейчас, не смотря на все кудахтанья, успехи раста сводятся к порче отдельных С/С++ проектов, которые теперь и собирать трудно и поддерживать не возможно из за смешения языков. Максимально бредовое утверждение. Тут уже кидали ссылки и на андроид. и на драйвер для М1 который прошел сертификацию кроноса, и на кучи утилит (от амазона, RustVMM, до ядра Maestro) > Поймите, вы просто свели прогресс на ноль за последние 20 лет, как минимум в сборке. Если ценой исправления дыряшек в памяти - то для меня это устроит. По большей части пострадают гентушники, но их и так не жалко. > В плане поддержки это полная абракадабра. Просто так скажи "я неосилятор, у меня мозг усох и нового я освоить не могу". > Фишка программ на С в том что они быстро и везде собираются, синтаксис понятен любому идиоту, и ошибки относительно легко исправляются, особенно современными инструментами. Хахахаха, кажется у тебя упал красный нос 🔴, возьми пожалуйста. Уязвимости живут в ядре по 5-10-15 лет. В овнопроектах типа хорг - так вообще 35. И где эти ваши инструменты? > У раста ничего этого нет, только иллюзия безопасности, иллюзия скорости и несъедобный синтаксис. Нет, нет и нет) Безопасность там именно такая как обещали. Скорость там сравнимая, можешь просветиться на benchmarksgame То что ты не моешь осилисть синтакс, так ты наверное просто старый.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	161. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Ivan_83 (ok), 25-Янв-24, 01:04
	> Можно и на улицу в кустики бегать, но люди предпочитают нормальный санузел. Так проблема в том, что вы этот санузел пытаетесь изуродовать со словами: - как бы мимо никто не пописал, потому надо писать сидя, вставляя катетор - как бы микробы не размножились потому надо перед использованием 10 дней проводить дезинфекцию а после использования нужно сносить и перестраивать заново > Если ценой исправления дыряшек в памяти - то для меня это устроит. По большей части пострадают гентушники, но их и так не жалко. Проблема только в том, что такие лезут к тем кого и так всё устраивает и доводят до неудовлетворительного состояния. > Уязвимости живут в ядре по 5-10-15 лет. В овнопроектах типа хорг - так вообще 35. И кому они помешали? > Скорость там сравнимая, можешь просветиться на benchmarksgame В лучшем случае с крестами, конкурентом чего и является гниль. Вот эти все гнилые владения и прочее - оно же не бесплатно в рантайме.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Аноним (110), 24-Янв-24, 17:55
	Кто о чем, а вшывый о расте. А ведь в коменте на который ты отвечал ни слова о расте. И да, один из безопасных языков это Ада. И Ада даже есть в гцц. Но диды упорно продолжают выходить за границы буфера.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	114. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (106), 24-Янв-24, 17:56
	Можно было просто написать "раньше было лучше, а теперь гогно, хотим быть идиотами" и получилось бы то же самое, но без балабольства.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	160. Скрыто модератором	+/–
	Сообщение от Аноним (-), 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 жрут. Компьютер нужен для того, чтобы он впахивал на благо человека, например на благо программиста, и старпёры, которые этого не понимают, и настаивают на том, что вручную набранный байтик чем-то духовнее и чище сгенерированного программно, демонстрируют стандартный тренд скатывания старпёров в маразм ближе к старости.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	165. Скрыто модератором	+/–
	Сообщение от Ivan_83 (ok), 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 жрут. Вот только лично для меня раст имеет отрицательную ценность, в отличии от чатгпт и прочего. > старпёры, которые этого не понимают, и настаивают на том, что вручную набранный байтик Старпёры, которые вам собирают линукс, венду и весь софт под них, просто говорят что такими темпами этот ваш раст приведёт к закату опенсорца, ибо его не возможно будет собрать дома.
	Ответить | Правка | Наверх | Cообщить модератору

	185. Скрыто модератором	+/–
	Сообщение от Аноним (-), 25-Янв-24, 11:27
	> Меня интересовало всегда как сделать так чтобы программа делала то что мне нужно. А, типичный ремесленник-самодельщик. Не, это тоже хорошо, никого даже не пытаюсь обидеть, но просто многое объясняет. > Нет, нонче 8+ ядер, 32+гб а всё тормозит так же как на втором пне 20+ лет назад. Мне кажется кто-то просто забыл КАК оно тормозило на втором пне 20+ лет назад. > Какойнить nginx не сильно то обложен ifdef для разных аппаратных платформ. Разумеется. Потому что он не сильно и взаимодействует с аппаратной частью. > Смысл в том, что тут базовых операторов очень мало и чтобы получить свой диалект нужно его в начале описать. Это и называется бедностью и невыразительностью синтаксиса. > Только вот контуженные вечно приходят и назязывают мне безопасность: то интернет надо отключить, то оружие сдать, то намордник одеть, теперь вот в компах мне зачем то надо всё на абракадабру переписывать и сутками ждать пока все проверки пройдут и оно запустится. О, так ты еще антиковидчик))) Это ооочень многое объясняет! > и сутками ждать пока все проверки Всем пофиг что у тебя комп с помойки. Твое мнение никого не интересует. Делай форк и поддерживай старый код. > И мне не нравится что эта гниль пролезает в проекты и мне приходится тратить своё время и на их поддержку и на их сборку. Как же ты их поддерживать будешь, если ты в раст ни в зуб ногой?)) > Вот только лично для меня раст имеет отрицательную ценность, в отличии от чатгпт и прочего. Опять же, на твое личное мнение всем как-то положить. > Старпёры, которые вам собирают линукс, венду и весь софт под них, просто говорят что такими темпами этот ваш раст приведёт к закату опенсорца, ибо его не возможно будет собрать дома. Старпёры, которые вам собирают линукс как раз добавляют раст, ну или как минимум не против этого. Пока что пованивают пара маргиналов, которые вот лично мне не собрали ни байта. Цифры в нике конечно не показатель, но такое ощущение, что там должно быть 73 или даже 63. Потому что... субъект, которого всё устраивает, ничему учиться не хочет, хочет чтобы все было как есть, древний комп, который даже раст не тянет (у меня на одном компе растософт собирается на интуле 2500, помните такой?, и собирается достаточно шустро, поэтому сложно представить что за древность у вас), банкингом не пользуется. В общем если подвести итоги... suck to be you, больше добавить нечего.
	Ответить | Правка | Наверх | Cообщить модератору

	202. Скрыто модератором	+/–
	Сообщение от Ivan_83 (ok), 25-Янв-24, 21:37
	> А, типичный ремесленник-самодельщик. Не, это тоже хорошо, никого даже не пытаюсь обидеть, но просто многое объясняет. А вас не смущает что я ориентирован на конечный результат а вы на процесс? > Мне кажется кто-то просто забыл КАК оно тормозило на втором пне 20+ лет назад. Нет, я помню как всё ускоприлось когда пень2 266 поменялся на пень3 1333. > Это и называется бедностью и невыразительностью синтаксиса. Вы жалуетесь что в алфавите мало буков?) Тут как говорится плохому пограмисту и язык вечно не торт :) > О, так ты еще антиковидчик))) Нет, я за свободу, даже если свобода сдохнуть. Мне где то в марте уже стало понятно что это лажа рускрученная СМИ, когда в италии никто замертво не падал на улице как в кетайских роликах. > Всем пофиг что у тебя комп с помойки. Твое мнение никого не интересует. Вы с этим заявлением приходите хотя бы лет через 10, пока что 5950х + 128гб ецц не тянет на помойку. А моё мнение - так я меинтейнер кое чего, так что если моё мнение не важно, то ищите себе других меинтейнеров. Только вряд ли у них условия и как результат мнение будут отличатся. А потом у таких какакодеров окажется что их мегапроект ни в одном дистре не представлен. > Как же ты их поддерживать будешь, если ты в раст ни в зуб ногой?)) А никак не буду. Сношайтесь вы с этим сами. Я пойду писать своё. В общем это мой ответ Home Assistant во много из за ихнего маразма с кучей петонячих модулей и многочисленных проблем с пикрипто который теперь с гнилью. > Опять же, на твое личное мнение всем как-то положить. И правда, только вот расту я не дам ни денег ни своего времени, и будут рекоменядовать с ним не связыватся и даже близко не подходить всем кто спросит. > Потому что... субъект, которого всё устраивает, ничему учиться не хочет, хочет чтобы все было как есть, древний комп, который даже раст не тянет (у меня на одном компе растософт собирается на интуле 2500, помните такой?, и собирается достаточно шустро, поэтому сложно представить что за древность у вас) Дорогой дружок, в жизни есть масса не решённых проблем, и переход с С на гниль не решает ни одной из них для меня лично, и даже наоборот создаёт их. Последние полтора года я был занят релокацией себя и семьи, от компов/телефонов/планшетов мне нужно было ровно одно: чтобы они работали а не чтобы я тратил своё время на поддержку их работоспособности. Сейчас интерес сместился в сторону получения денег, и опять же тратить время на гниль - это тратить время с отрицательным результатом. Есть ещё тема с умным домом, где гниль опять же только мешается ибо только добавляет проблем усложняя поддержку Home Assistant. Гниль - это 99% усилий для решения 5% проблем. Как только вы перестанете заморачиватся процессом и начнёте думать за результат (который не в том чтобы не было уязвимостей) то всё поймёте. > банкингом не пользуется. Не знаю как вы, но у меня был "ВИП" банкинг и в РФ и теперь тут тоже. Свой персональный манагер, доступ к управлению счетами через инет. В РФ я это делал через браузер, тут через приложение. Я уже встречался с местным аналогом грефа и местными пилильщиками банковского приложения чтобы пофиксить то что у меня в нём не работало. И переодически шлю пожелания (багрепорты) разрабам и их начальству с тем что не так. Потому не пытайтесь смешить меня словами про банкинг, ибо вы жрёте что дают и даже посолить попросить не можете. Но банкинг нынче не торт - он для мало обеспеченных с депозитами до 10к бачей, надо валить в крипту, если деньги есть.
	Ответить | Правка | Наверх | Cообщить модератору

	204. Скрыто модератором	+/–
	Сообщение от n00by (ok), 26-Янв-24, 08:03
	>> Ты когда в последний раз открывал учебники по Computer Science? Когда в последний раз интересовался теорией того, как можно добиваться от программы предсказуемого поведения? Когда в последний раз интересовался тем, как эта теория в практику претворяется? > НИ-КО-Г-ДА! А вот и напрасно. Теория -- любопытная штука. :) Фишка в том, что доказательство корректности тривиально, когда программа состоит из чистых функций. Чистая - это когда не хранится состояние и нет побочного эффекта. А побочный эффект - это и есть результат, ради которого мы запускаем программу. :) На практике Haskell -- очень хороший язык, но он слишком ленив и потому написано мало. Rust - внешне похож на функциональный (нет императивного return), но если об этом заговорить с любителями языка, выясняется, что они боятся повторить судьбу Хаскеля.
	Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

	175. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–1 +/–
	Сообщение от Аноним (175), 25-Янв-24, 09:31
	>синтаксис понятен любому идиоту ага особенно с void (*functionPtr)(void); и всякие && || ^ & | << >>
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	181. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+2 +/–
	Сообщение от Совершенно другой аноним (?), 25-Янв-24, 10:42
	Но согласитесь, у Rust с этим гораздо хуже.. fn longest<'a, 'b : 'a>(x: &'a String, y: &'b String) -> &'a String { ... } Почему-то сразу вспоминается Говард Лавкрафт с его "Пх'нглуи мглв'нафх Ктулху Р'льех вгах'нагл фхтагн".
	Ответить | Правка | Наверх | Cообщить модератору

	189. "Уязвимость в утилите 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) );})
	Ответить | Правка | Наверх | Cообщить модератору

	191. "Уязвимость в утилите 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) );}) В Вашем примере как-раз такого и нет, но есть обилие скобок.
	Ответить | Правка | Наверх | Cообщить модератору

	195. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от n00by (ok), 25-Янв-24, 16:39
	> Когда два подряд спец-символа, как-то глаз спотыкается и выглядит не > очень как по мне. Это про одинарную кавычку? Она ж во многих языках требует закрывающей пары. Потому и не читается.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Ivan_83 (ok), 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 не падал, иначе можно было просто скастовать и пофиг что оно там может быть не выровнено.
	Ответить | Правка | К родителю #189 | Наверх | Cообщить модератору

	182. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Bottle (?), 25-Янв-24, 11:01
	>Фишка программ на С в том что они быстро и везде собираются Ахахаха, расскажи это разработчикам ядра Линукс. Особенно Инго Молнару, который целый год потратил на оптимизацию заголовочных файлов ядра, чтобы оно быстрее собиралось.
	Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

	198. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (198), 25-Янв-24, 18:40
	Растоманам лучше помалкивать о скорости сборки, а то выйдет неудобно :)
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от RM (ok), 24-Янв-24, 19:29
	Вот кстати почитать про palloc было занимательно, я например не знал что оно и зачем надо
	Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

29. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+2 +/–
Сообщение от Серб (ok), 24-Янв-24, 12:35
Забавный патч. Просто удаляет реалокацию? Она там вообще не нужна была?
Ответить | Правка | Наверх | Cообщить модератору

	33. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–1 +/–
	Сообщение от пох. (?), 24-Янв-24, 12:41
	конкретно в этом месте она была очевидно вообще мимо тазика. А то что там поулучшайкали в целом - патч не удаляет, оно теперь навеки с нами.
	Ответить | Правка | Наверх | Cообщить модератору

	74. Скрыто модератором	+/–
	Сообщение от Аноним (75), 24-Янв-24, 15:14
	О, пох, здоровеньки булы! Долго жить будете, однако! Крайний раз, когда доводилось общаться, Вы помирать уж собирались. А я и говорил, что в поряде будете. За это время я сам чуть ласты не склеил и потерял все мирское. В общем рад, что с Вами ок. В целом всех рад видеть, особенно полтора анончика, конечно же! Мир вам, пацаны. Что вообще нонче в мире ит происходит? Пингвин еще не лопнул от жЫра? Нуби залечил свою боль? Михаэль уже вывел отечественные ОС в лидеры рынка БРИКС?
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (75), 24-Янв-24, 15:50
	О, вижу некие инновации. А говорили бот-модератор, ии, вот это все...а за ширмой как всегда Васян.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	100. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от n00by (ok), 24-Янв-24, 17:10
	shrink - это урезать буфер. "Преждевременная оптимизация - корень всех зол."
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	169. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–1 +/–
	Сообщение от Аноним (169), 25-Янв-24, 02:45
	> Преждевременная Сколько десятилетий этому коду? Это по человеческим меркам уже глубокий пенсионер, а вы размышляете отдавать ли его в детский садик или рановато ещё...
	Ответить | Правка | Наверх | Cообщить модератору

	180. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от n00by (ok), 25-Янв-24, 10:31
	> вы размышляете отдавать ли его в детский садик или рановато ещё... Читаете мои мысли? Доктор в курсе?
	Ответить | Правка | Наверх | Cообщить модератору

52. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
Сообщение от Аноним (52), 24-Янв-24, 13:54
>возникающих при использовании утилиты split для разделения данных, передаваемых при помощи QR-кодов Баш-скрипты надо запретить. Использовали бы питон - такой проблемы бы не было. Это им ещё повезло, если на выполнение данных, переданных в коде, как команды шелла не нарвались.
Ответить | Правка | Наверх | Cообщить модератору

	58. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (53), 24-Янв-24, 13:59
	> Баш-скрипты надо запретить. Одна из ключевых проблем баша — то, что он позволяет запускать программы, которые были написаны на сишке. Ещё одна — то, что он сам является такой программой. Питон (по крайней мере, классический cpython) в этом плане не сильно лучше.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (169), 25-Янв-24, 02:43
	> Одна из ключевых проблем баша — то, что он позволяет запускать программы, которые были написаны на сишке. Погодите, давайте понаблюдаем как этот зумер переизобретёт идеальный сферический Java-процессор...
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (66), 24-Янв-24, 14:47
	Ну ещё бы shell не позволял запускать исполняемые ELF-файлы. Толку тогда от него.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

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

	81. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–2 +/–
	Сообщение от Аноним (81), 24-Янв-24, 15:41
	Унас есть такая пословица >you are only as good, as your tools. Хоть ты сто раз мнишь себя гением, если ты используешь баш вместо питона, то есть выбрал неправильный инструмент для задачи, то ты не гений.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (57), 24-Янв-24, 16:05
	Желание везде пихать любимый яп вместо баша тоже детектор отклонений кстати.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (106), 24-Янв-24, 17:54
	Баш это клей для конвейеров. Если вы используете что-то большее, чем вызовы и циклы - скорей всего вы выбрали баш неправильно.
	Ответить | Правка | Наверх | Cообщить модератору

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

	131. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (128), 24-Янв-24, 19:10
	> писать придется прям существенно больше И вот тут бы примеры привести, но нет, User не смог для этого встать с дивана.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от User (??), 24-Янв-24, 21:26
	>> писать придется прям существенно больше > И вот тут бы примеры привести, но нет, User не смог для > этого встать с дивана. Ээээм... возьмите любой однострочник на баше (Ну хоть один-то видеть должны были, да?), чтоли - и попробуйте его в python-скрипт преобразовать. Фиг с ним с бойлерплейтом (Хотя его тоже больше) - таки ж ведь и кода больше придется писать.
	Ответить | Правка | Наверх | Cообщить модератору

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

	173. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от User (??), 25-Янв-24, 08:11
	> Ты неправ, баш приспособлен под определённые задачи куда лучше любых альтернатив. И > да, кода меньше. В том плане, что не "более высокоуровневый", а "фактически DSL"? >Как мне видится, основное его ограничение в том, > что всё, по-сути, строки, и нет возможности эффективно оперировать байтовыми последовательностями > (в частности, больше всего не хватает IFS=\0 или чего-нибудь вроде того). > К 45 годам нагромождений легаси и ограничений можно привыкнуть, к невозможности > работать с произвольными именами файлов без find -- нет. В тикле кстати все тоже строки - и в общем-то норм. А за шеллом, построенным на принципах моложе поздних 70х\ранних 80х - вам пожалуй что в microsoft :). Xonsh\ipython все же сиииильно не дотягивают - те же яйца, вид в профиль.
	Ответить | Правка | Наверх | Cообщить модератору

	167. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (169), 25-Янв-24, 02:40
	Проблема с башем та же, что и с Перлом - сплошной write-only код получается, наполовину состоящий из спецсимволов. Конечно очень сжато получается, только этот код через год сам автор не разберёт.
	Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

	172. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от User (??), 25-Янв-24, 07:12
	> Проблема с башем та же, что и с Перлом - сплошной write-only > код получается, наполовину состоящий из спецсимволов. Конечно очень сжато получается, > только этот код через год сам автор не разберёт. Так никто не говорит, что это "хороший" язык. Просто - "более высокоуровневый".
	Ответить | Правка | Наверх | Cообщить модератору

	206. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (206), 27-Янв-24, 01:02
	Использовать надо Nushell, а не Питон.  Питон - как и любой язык не имеющий удобной интеграции с командной строкой - плохо подходит под скриптование.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

104. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
Сообщение от Аноним (104), 24-Янв-24, 17:41
А в чем уязвимость? Переполнения отлавливаются железом и программа завершается
Ответить | Правка | Наверх | Cообщить модератору

	132. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (66), 24-Янв-24, 19:21
	Как повезёт. Если переполнение выйдет за границу страницы памяти, то отловится.
	Ответить | Правка | Наверх | Cообщить модератору

129. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+4 +/–
Сообщение от Аноним (128), 24-Янв-24, 19:08
Никогда такого не было, и вот опять: ненастоящие сишники прокрались в GNU и накодили там CVE.
Ответить | Правка | Наверх | Cообщить модератору

	133. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+/–
	Сообщение от Аноним (66), 24-Янв-24, 19:24
	"Ненастоящие" и в GNU пробрались. И в GNU были наезжавшие на Столмана.
	Ответить | Правка | Наверх | Cообщить модератору

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

	134. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	+1 +/–
	Сообщение от Аноним (75), 24-Янв-24, 19:26
	Вот бсдишечка от гнутого софта и избавляется потихоньку. #все правильно делают! Бсди чмафки и любимки111!
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

166. "Уязвимость в утилите GNU split, приводящая к переполнению бу..."	–3 +/–
Сообщение от Аноним (169), 25-Янв-24, 02:37
> при замене вызова функции xrealloc на xpalloc Угу, типа починили, до следующего раза. А вот писали бы на современном C++  - не пришлось бы заниматься мартышкиным трудом по ручному управлению памятью..
Ответить | Правка | Наверх | Cообщить модератору

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

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

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