The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

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

Подробнее: https://www.opennet.dev/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 
Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

165. Скрыто модератором  +/
Сообщение от Ivan_83 (ok), 25-Янв-24, 01:49 
Ответить | Правка | Наверх | Cообщить модератору

185. Скрыто модератором  +/
Сообщение от Аноним (-), 25-Янв-24, 11:27 
Ответить | Правка | Наверх | Cообщить модератору

202. Скрыто модератором  +/
Сообщение от Ivan_83 (ok), 25-Янв-24, 21:37 
Ответить | Правка | Наверх | Cообщить модератору

204. Скрыто модератором  +/
Сообщение от n00by (ok), 26-Янв-24, 08:03 
Ответить | Правка | К родителю #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 | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру