The OpenNET Project / Index page

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



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

Оглавление

Уязвимость в утилите GNU split, приводящая к переполнению буфера, opennews (??), 24-Янв-24, (0) [смотреть все]

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


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ообщить модератору

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

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




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

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