В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64093
Это успех, я считаю!Кто со мной согласен - ставим плюсик
Не просто плюсик, а ++ - два плюсика.
С плюсом-плюсом XD
Наконец-то хорошая новость.
И слепой поведёт слепого.
но ведь... но безопасно же и боровы чекают и вообще, нельзя выйти за границу массива и безопасная работа с памятью
По-любому нейронка код генерировала
> Это успех, я считаю!
> Кто со мной согласен - ставим плюсик[X] Achievement unlocked: запилить CVE на Rust.
Вы не понимаете! Это другое!
А ты зоркий. Молодец, заметил - именно что другое. А то бы налетели сейчас местные сишники-ПравильныеПогромисты... Никаких тебе выходов за пределы буфера, обращения к освобожденной памяти или двойного освобождения памяти... Ну, именно того, от чего и должен спасать раст. А просто "логическая" ошибка. От которой никто не обещал (и не мог) защитить. Не в той позиции что-то там в файле считали и не проверили. Ну это те самые гугловско-майкрософтовские оставшиеся "30% ошибок", которые уже только напряжением мозгов нужно избегать.
В новости ошибка работы с памятью. Да, ошибка не с оперативной памятью.
Так выход за границы массива это логическая ошибка или нет? Если программист на Си ошибётся в размере массива, то это одно, а когда на rust ошибка с размером в структуре данных, то это другое?
Нет, дружочек, это одного рода проблемы. Да, rust спасает от ошибок с оперативной памятью, с этим спорить не буду.
> В новости ошибка работы с памятью.В новости ошибка с неправильной интерпретацией спецификации
В файле стоит
Заголовок ustar:
размер этого файла 0 байт
Заголовок PAX:
размер этого файла 20мбайтСтарая реализация приоритетной считала значение из ustar, читала 0 байт файла, и дальше читала вложенный tar как содержимое основного tar файла
А должна была читать PAX, и пропускать 20мбайт как содержимое файла
Спека говно, и точно таким же образом обсираются все реализации tar которые PAX не поддерживают.
PAX является якобы обратно совместимым, поскольку данные от него пропускаются легаси реализациями, однако он может содержать в себе копию размера, от чего и возможны такие конфликты
Если одну и ту же информацию хранить больше чем в одном месте - рано или поздно содержимое копий не совпадет. "И чо тогда?"
На... т.е. зачем было добавлять еще одно поле размера, особенно если старое все еще должно быть совместимо, т.е. о увеличении разрядности речь не идёт - непонятно совсем.
Похоже спека таки кривая, т.е. непродуманая.
> Так выход за границы массива это логическая ошибка или нет? Если программист на Си ошибётся в размере массиваЧисто казуистический прием. Разницу-то в ошибках вы (да все остальные) всё равно поняли ;) Да, да, старая проблема при холиварах на этом сайте: как же обозвать все эти разные ошибки. Но тут уже более распространено мнение/определение, что есть ошибки работы с памятью (те 70% о которых гугл распинался), а есть остальные, "логические" (вот как раз когда не то или не оттуда считали или введенное значение на допустимость значений не проверили или когда уставший сонный программист знаки больше с меньше перепутал).
> Если программист на Си ошибётся в размере массива, то это одно, а когда на rust ошибка с размером в структуре данных, то это другое?
Это просто офигенно другое! И если ты этого честно не понимаешь (сомневаюсь в этом), то ты просто профнепригоден.
> Нет, дружочек, это одного рода проблемы
Не дружок ты мне пока, а тролль. И это очень разного рода проблемы.
> а есть остальные, "логические" (вот как раз когда не то или не оттуда считали или введенное значение на допустимость значений не проверили или когда уставший сонный программист знаки больше с меньше перепутал).Так выход за границы массива – это буквально всё, что вы перечислили.
Считали неопределённые данные.
Не проверили границу.
Уставший сонный программист запутался в инкременте в цикле for.
Уровень кекспертизы подоспел.
У вас есть буфер с содержимым "слово" из 5 символов.
По спецификации нужно прочитать третью букву "о", вы этого не поняли и прочитали букву в. Где здесь ошибка работы с памятью и где выходит за границы массива?
>> > а есть остальные, "логические" (вот как раз когда не то или не оттуда считали или введенное значение на допустимость значений не проверили или когда уставший сонный программист знаки больше с меньше перепутал).
> Так выход за границы массива – это буквально всё, что вы перечислили.И тут врёте и всё перекручиваете. Говорю же, казуистика. Брехня.
>Считали данные не с того места.
Где тут выход за пределы массива? Я может потом просто захочу создать массив на это считанное откуда-то число элементов. Считал какие-то данные - не значит что полез в массив по смещению или без проверки сложил значение с указателем, как в сишечке.
> Не проверили границу.
Где там про проверку _границ_ написано? Сами слово добавили и сами обвиняете? Допустимость значений - это типа "остаток на счете должен быть больше либо равен нулю". Где здесь граница? Да и в расте ты так просто и "незаметно", как в си, не выйдешь за границу массива.
> Уставший сонный программист запутался в инкременте в цикле for.
и не будешь лишний раз инкрементами в циклах баловаться - в большинстве случаев просто итераторами пробежишься и никуда за границы массива не вывалишься.
>Так выход за границы массива это логическая ошибка или нет?В новости ничего не говорится о выходе за границы массива, Rust от такого защищает.
>Если программист на Си ошибётся в размере массиваТо будет порча памяти.
>а когда на rust ошибка с размером в структуре данныхПорчи памяти не будет. Вы не сможете прочитать/записать в чужую память, только в свою.
>то это другое?Да, другое. В случае сишной уязвимости, при распаковке можно было бы вызвать условный curl | bash, здесь - только переписать файлы.
> В случае сишной уязвимости, при распаковке можно было бы вызвать условный curl | bashНельзя. С чего бы? Если речь только про ошибку при обработке данных, а не ошибке работы с ram.
С того, что ошибки обработки данных в сишных программах встречаются редко, а вот ошибки управления памятью - часто.
> оставшиеся "30% ошибок", которые уже только напряжением мозгов нужно избегатьНу раз напряжением мозгов, то софт на расте точно обречён. Ибо в него и привлекают-то лишь всякими "вам больше не нужно думать о размере буферов и указателях", а основная масса растофанов прекращает читать на слове "думать".
Так это же замечательно, что какой-то инструмент позволяет не думать о том, что к делу не относится и сосредоточиться на прикладной задаче.Необходимость байтодрочерства и прочих ручных управлениях всем, чем можно, пошло от общей убогости компьютерных технологий прошлого (да и нынешнего), а не потому, что это исходно и хотели делать изобретая ЭВМ...
Вот сосредоточиться на прикладной задаче чет не получается.
Тогда пиши на луа и питоне
> инструмент позволяет не думать о том, что к делу не относитсяЭто точно не про rust.
Он именно заставляет и очень много думать о том что к делу не относится.
На другой тип ошибок нужен еще один ЯП!
Может, Zig?
Хороший вариант. Вон, в Редоксе на него драйвера переписывают.
Да ну?! А что же с Растом не так?
А сколько багов остаются незамеченными тупо из-за того, что раст вынуждает писать нечитаемую лапшу и раздувать изначально компактный код в несколько раз
нечитаемая она для местных сишников. А кто вкатился в эту тему и какое-то время в этом варился - заявляют, что всё прекрасно читается и понимается. Дело привычки. А техдир гугла еще и заявляет что команды, разрабатывающие проекты на расте, в два раза продуктивнее команд сиплюсплюсников. Предположу, что командная работа с "нечитаемой лапшой" не могла бы быть в два раза продуктивнее "абсолютно понятных" божественных плюсов.
Ты даже не понимаешь о чем речь, сразу видно что вкатился и варился. Когда даже книжный алгоритм приходится перелопачивать так, что он становится сам на себя не похож. Сколько из-за таких выкрутасов в коде возникает логических ошибок, невозможно и представить. Пока нормальные люди пишут код так, чтобы он был легко читаем и понятен, такие как ты варятся и вкатываются и навязывают остальным свои шизоидные извращения. Необходимы клиники для реабилитации, а еще лучше принудительные работы не связанные с компьютерами
> нормальные люди пишут код так, чтобы он был легко читаем и понятенАга, видели мы тот код "от нормальных людей"
Как тебе функция-портянка на 1000+ строк кода?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Естественно с кучей кала в виде goto - нормальной обработки ошибок ведь не завезли...И ведь это ядро! Его же пишут профи))
> Необходимы клиники для реабилитации, а еще лучше принудительные работы не связанные с компьютерами
А принудительная стререлизация, ну чтобы уже на 100% как faшики, будет?
На расте функция конечно будет не 1000 строк, размер функций же от ЯП зависит
Функцию на тысячу строк можно на любом языке написать, если что. Понимать подобный код на Rust будет также сложно как на C с goto, поскольку только в Rust и regex смысл строки может кардинально измениться всего из-за одного символа. Неудивительно, что без ИИ с ним не разобраться.
> поскольку в Rust смысл строки может кардинально
> измениться всего из-за одного символа.А теперь приведи хоть один пример когда такое может произойти
> Естественно с кучей кала в виде goto - нормальной обработки ошибок ведь
> не завезли...Вот интересно, обработка ошибок по твоему она магическая какая-то или ей занимается отдельный код? Настоящий кал - это как раз запихать в ядро код обработчиков ошибок. Задумайся почему в ядре даже стандартных библиотек нет.
Лапшекод из goto осуждал ещё Дейкстра. Для нормальной обработки нужен как минимум типы Option и Result. А не спагетти, когда выполнение прыгает туда-сюда.
>Вот интересно, обработка ошибок по твоему она магическая какая-то или ей занимается отдельный код?Да магическая. Поскольку goto ограничен пределами текущей функции, си вынуждает растягивать определния, в то время как монадическая обработка(как минимум) позволяет разбивать функцию на мелкие части.
>Настоящий кал - это как раз запихать в ядро код обработчиков ошибок.Он уже там есть, только в виде лапши из goto.
> Да магическая. Поскольку goto ограничен пределами текущей функции, си вынуждает растягивать определния, в то время как монадическая обработка(как минимум) позволяет разбивать функцию на мелкие части.Причем тут монадическая обработка? Обработка исключений вроде try ... catch в C++ (и других языках) - это не синтаксический сахар, а генерация отдельного кода под это дело, даже не всегда тривиального. В ядре же стараются избегать неявного кода.
Похоже, вы в упор не понимаете разницу между готовыми абстракциями (которые предоставляет Rust) и собственным велосипедом (который из проекта в проект изобретают программисты на C).
>собственным велосипедом (который из проекта в проект изобретают программисты на CЭ погоди! Ты делаешь необоснованный вброс о том, что велосипеды это плохо. Если сишник начнёт делать что-то более менее верхеуровневое, он неизбежно станет программировать то, что уже до него кто-то делал. Это нормально.
> Вот интересно, обработка ошибок по твоему она магическая какая-то или ей занимается отдельный код?Ага.
Например инвариант который проверит все возможные состояния.> Настоящий кал - это как раз запихать в ядро код обработчиков ошибок. Задумайся почему в ядре даже стандартных библиотек нет.
Потому что ведро писал студент, а там как получилось)
Зато в ядре есть 100500 велосипедов, про которые этот самый бывший студент недавно говорил: "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."
Напомню что в недоязыках на старте не было даже структуры String не было.
А поддержка UTF до сих пор хромает.
>Напомню что в недоязыках на старте не было даже структуры String не было.Так и сейчас нет.
не очень понял про код - что не так? обработка ошибок на готу в конце функции. можно сделать f(x) f2(x, e), e = ..., но тогда придётся тянуть контекст для корректного завершения в ветках. определять для них и структуру и код-функцию finalize? и имена для каждой ветки-сущности, получается.а как это делают правильно, может, в лучших языках?
> Когда даже книжный алгоритм приходится перелопачивать так, что он становится сам на себя не похож.Из этой фразы любому программисту видно, что ты алгоритм заучил, а не понял. Что однозначно определяет тебя как кодера на одном языке, которому никакая клиника уже не поможет.
Мне видно что ты читать не умеешь или какие-то ограничения в мыслительном аппарате, хз. Это где-то в первом классе у детей спрашивают про что пословица "без труда не вытащишь и рыбку из пруда" и они отвечают "про рыбку"
Так а что же ты про техдира гугла не завернул? Вот же он наверное лох, похоже из клиники для реабилитации выступал. Ну или его подло обманули агенты раста с метриками разработки, подло оболгав плюсовиков. Но я конечно поверю тебе, а не ему.> Ты даже не понимаешь о чем речь, сразу видно что вкатился и варился
К твоему сожалению, правда совсем-совсем немного, понимаю. Года три назад, не зная языка, "не вкатываясь", просто взяв примеры кода и подправив их под себя, сделал себе утилитку, работающую с внешними ресурсами (отчеты с биржи стягивает). _Почти_ всё там было понятно и аккуратно. Но да, язык учить надо. Сложное так просто не напишешь. Впрочем, как и на си.
8 лет разрабатываю на Rust, с такими проблемами не сталкивался.
Это проблема только для олимпиадников, которые алгоритмы зазубрили как стишок. Если понимаешь суть алгоритма, нет никаких проблем в том, чтобы его реализовать с ограничениями ownership. (Да, в ряде частных случаев такая реализация станет менее эффективной - тут всегда выбор, или с этим мириться, или воткнуть unsafe. Но это редкость).
> Да, в ряде частных случаев такая реализация станет менее эффективнойРечь не про эффективность, а про читаемость.
Если алгоритм изменен и накручен(когда в разных условиях разные алгоритмы выбираются, иногда с откатом) вот тут без читаемости вообще никак. У rust с этим никак.
Будет очень много кода для обеспечения бесопастности.
Читаемость - понятие субъективное. Для меня процедурные портянки на сто строк нечитаемы, кому-то в цепочках коротких вызовов сложно разобраться и хочется видеть привычную портянку.А "обеспечение безопасности" - опять же, it depends. Если алгоритм сразу "строить" под модель и писать идиоматический код, все будет прекрасно. Да, не всегда это возможно (те же doubly linked lists), и приходится городить огород, но сами doubly linked lists штука такая, что без заката солнца вручную и очень внимательного программирования их безопасными не сделать.
> а, не всегда это возможно (те же doubly linked lists), и приходится городить огород, но сами doubly linked lists штука такая, что без заката солнца вручную и очень внимательного программирования их безопасными не сделать.Любой откат в алгоритмах приводит к необходимости иметь циклические структуры.
> и раздувать изначально компактный код в несколько рази вдогонку, из соседней новости, про принятие в ядро Linux 6.18 реализации Binder IPC для Android, написанная на Rust:
"...Несмотря на продвинутые возможности и поддержку объектов со сложной семантикой владения, драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода."
Ну т.е. после этого нам _очень_ интересно твое "икспертное" мнение. Ты наверное много программ написал сразу в двух вариантах - на си и на расте, чтобы сравнить и выдать свои ценные замечания, верно? Ведь верно?
Сотни других неудобных примеров мы конечно проигнорируем, да?
Эти "сотни других неудобных примеров" только в Вашей голове? Откуда сотни примеров, если Вы и Ваши соратники утверждаете, что на расте вообще ничего не написано?
Ничего не пишут, только переписывают
> Ничего не пишут, только переписываютотлично, о том и разговор.
значит ты легко приведеш примеры где перерисывание с С на Раст раздуло исходники.
> отлично, о том и разговор. значит ты легко приведеш примеры где перерисывание с С на Раст раздуло исходники.Лучше приведи, где переписыватели полностью реализовали всю функциональность для всех архитектур на которых используется оригинал.
> Сотни других неудобных примеров мы конечно проигнорируем, да?Какие сотни, если ты ни одного не привел?
Тебе вон дали буквально из соседней новости: кодя в Linux залит, и по сравнению с сишным стал не только проще, но и компактнее.
Скажешь что-то сожержательное?
Ну даже тут на opennete была куча примеров, что переписали драйвер на расте, функционал меньше, объем кода больше, мне лень гуглить, если у тебя память как у золотой рыбки, какой смысл мне тратить на это время? Все равно ты через секунду забудешь, бросай ты растоманство, совсем с головой худо будет
> на opennete была куча примеров, что переписали драйвер на расте, функционал меньше, объем кода большеНе, друг, давай ссылки с цифрами. Пока что ты выдаешь только дешевый треп.
Он не сможет. Ибо нет базы для сравнения. Приведи лучше пример ПОЛНОСТЬЮ переписанного.Нужно что бы была реализована полностью функциональность оригинала и работало на всех платформах, на которых работал оригинал.
в одну строку поди писали, все равно ведь раст нечитаемый.
>в одну строку поди писали1. Зачем вы свои проблемы проецируете на других?
2. Чтобы не заниматься догадками, можно полезть в исходный код и посмотреть самостоятельно. Или такое действие слишком сложно для типичного "эксперта“, воина борьбы супротив Rust?
Спойлер. Нет, в одну строчку на Rust (как и на любом другом языке программирования) типичные программисты не пишут.
> Чтобы не заниматься догадками, можно полезть в исходный код и посмотреть самостоятельноА что им смотреть, если они сами пишут, что синтаксис Раста не осилили? Они ж не поймут ничего! 😂
А в байтах какова разница, за вычетом комментариев?
Я
//комментарий раз
могу
//комментарий два
оформить
//комментарий три
предложение
/* очередной бесполезный блок
с комментарием */
так.
Строк многовато вышло, меряться оформлением - так себе затея. А что, индусам за количество строк платили где-то когда-то..Кто-то вообще макросами не часто пользуется, или любит "копировать -> вставить" подобные куски с небольшими отличиями вместо inline с параметрами (навскидку подумалось).
Мне вот больше интересен результат сборки из исходников: быстродействие, применение внешних библиотек, определение/задействование возможностей исполняющей техники (всякие sse, avx, gpu вычисления и прочее-прочее) и всякие UB в исполняемом файле.
Лапша есть и возможна на каждом языке программирования.
Скажите вот эта растовая лапша, почему она вас так цепляет? Давайте проверим.
Макфа? Есть реакция?
Есентуки?
Медведь?
Анон?
Opennet?
Может быть Дядюшка Боб? Что-то есть фиксирую, мы теряем пациента, быстрее введите ему чистый код внутревенно.
Фух вроде отпустило?А если серьезно даже не знаю чел сходи до книжного и прочитай чистая архитектура и идеальная работа.
>Лапша есть и возможна на каждом языке программирования.Не на каждом. Достаточно убрать goto и количество лапши уже резко упадёт.
Как раз таки вырастет и читаемость упадет.
> А сколько багов остаются незамеченными тупо из-за того, что раст вынуждает писать нечитаемую лапшуОткроем-ка осоеднюю новость: https://www.opennet.dev/opennews/art.shtml?num=64092
“Использование Rust позволило решить некоторые проблемы с которыми сталкивались разработчики Binder, включая ошибки, связанные с подсчётом ссылок, блокировками и проверкой границ, а также значительно уменьшить сложность обработки ошибок.“
Смотри, эксперт, количество ошибок при использовании Раста только убавилось. Как так?
> раздувать изначально компактный код в несколько раз
Из той же новости:
"драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода."
Смотри, Растовый код не только не раздулся по сравнению с изначальным сишным, но даже стал меньше его! Как так? 😭
> Как так? 😭Боюсь, внятного ответа по теме мы уже не получим. Воин против Раста вон плюсиков за свой вброс получил от собратьев - и все, миссия выполнена.
>Смотри, эксперт, количество ошибок при использовании Раста только убавилось. Как так?Ответ в той же новости: за 15 лет развития "в старом коде накопился заметный технический долг, который усложнял как поиск ошибок, так и дальнейшую разработку. "
>Смотри, Растовый код не только не раздулся по сравнению с изначальным сишным, но даже стал меньше его!300 строк разницы после переписывания с нуля? Если бы переписали на том же языке, результат мог быть лучше
мимо-эксперт
> 300 строк разницы после переписывания с нуля? Если бы переписали на том же языке, результат мог быть лучшеА мог бы и не быть.
Т.к инструмент остался тот же. Те же goto и отсуттсвие нормальных проверок ошибок, те же километровые функции, и тд
Мог бы ты каменным топором построить современный дом?
>А мог бы и не быть.Не мог бы. Переписывание с нуля кода "с багажом" всегда даёт более компактный и аккуратный код
> Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.Т.е проблема в том что спецификацию расширили не пойми как, включив несколько размеров для одного и того же файла, и интерпретация спеки на Rust выбрала из двух размеров не тот.
Остаётся вопрос почему размер из PAX должен иметь приоритет, ведь теперь проблема может быть обратной - реализации TAR без поддержки PAX будут читать архивы иначе чем исправленная версия.
Legacy? Не, не слышал. Конечно же, виновата спека, а не святые растоманы.
> Legacy? Не, не слышал. Конечно же, виновата спека, а не святые растоманы.Так легаси точно так же этот PAX не читают и точно так же обосрутся как и реализация на Rust)
> спецификацию расширили не пойми какТам всё ещё интереснее. Этих форматов tar было как собак нерезаных. Когда POSIX решил это дело стандартизовать, он взял два формата ustar и PAX и объединил их в один. Это не расширение, это просто какой-то толпоиппизм. Я как-то думал написать реализацию tar в образовательных целях, в рамках ознакомления с каким-то очередным язычком программирования (а заодно и с tar ознакомиться), и забил именно из-за того, что разбираться со всеми этими завихрениями дидовского мышления не было никакого желания.
Но за этим, на самом деле, прячется целая дидовская философия: работает, не трожь. Вместо того, чтобы сделать по уму, они пытаются сделать так, чтобы ничего не делать. Ну, точнее, пытались. Сейчас они наверное все на пенсии уже. Продолжают пытаться ничего не делать.
> Остаётся вопрос почему размер из PAX должен иметь приоритет
На этот вопрос ответить определённо я не могу, увы. Меня не хватило на то, чтобы изучить историю вопроса. Но это намекает на вероятный ответ (тавтологию): если для понимания современного положения дел надо изучать историю вопроса, значит это легаси, где решения определяются не здравым смыслом, а броуновским движением истории, где стандарты не создают реальность, а фиксируют её такой, какая она есть. Отливают её в граните, чтобы и потомкам наших потомков досталось бы.
> стандарты не создают реальность, а фиксируют её такой, какая она естьЕсть два вида стандартов: те, которые фиксируют реальность (обычно с правками тех вещей, которые всех бесят), и те, которые разработаны комитетом (обычно в попытке сформировать реальность).
> Есть два вида стандартов: те, которые фиксируют реальность (обычно с правками тех
> вещей, которые всех бесят), и те, которые разработаны комитетом (обычно в
> попытке сформировать реальность).Но с tar третий случай, потому что совместили 2 несовместимых формата и теперь во всех tar архивах есть потенциально противоречащая информация
Ну, это просто доказывает что программисты тупые. Какой язык им не дай, уязвимости из за неправильного подсчета они все равно умудрятся сделать.А шуму то было, мол на расте уязвимостей вообще быть не может, щас как заживем, ух!
> А шуму то было, мол на расте уязвимостей вообще быть не можетЭто от вас, сишников, этот шум. Из раза в раз. От растовиков шум - не будет _только ошибок работы с памятью_ (если не пользоваться ансейфом), а не "всех-всех-всех ошибок". И их, ошибок по памяти, таки пока что-то не наблюдается в товарных количествах, как на божественном.
> От растовиков шум - не будет _только ошибок работы с памятью_ (если не пользоваться ансейфом), а не "всех-всех-всех ошибок"не-не, там еще шум, что раз нет ошибок с памятью, то будет больше времени отловить остальные.
Вот отлов и пошел — tar не так распаковывается, с md5 тоже что-то не так
Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфера
> Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфераФфух, мне даже как-то легче стало. Так вот какими они должны быть -- баги на расте! Если я в программе на C сделаю баг как на расте -- можно? Или это будет опять позорный дыряшечный дидовский баг? Или такие баги разрешено делать только на расте, а всем остальным -- ни-ни, не трогай, это на новый год... ой, то есть для раста? Короче, можно полную инструкцию, какими должны быть правильные баги?
Объясняю, почему так вышло - потому что в программе на Си такой баг тоже будет. Но прежде, чем поймать его, вы будете ловить переполнения буффера, двойное освобождение и прочие подобные баги памяти, и только потом логические. А тут вот ловятся сразу уже логические баги. Экономия времени
Во-первых, все баги которые могут случится на чистом Си хорошо документированы и описаны. Кто пишет на чистом Си, и реально желает избежать багов, тот их избежит. Вина в не внимательности и торопливости.>А тут вот ловятся сразу уже логические баги. Экономия времени
Дело не в характере ошибок, делов их в количестве. Не думаю, что общее количество ошибок на Расте меньше, чем в Си.
>Во-первых, все баги которые могут случится на чистом Си хорошо документированы и описаны.Часть багов, которые могут случится на си созданы разработчиками си и называются UB. Ещё часть багов никак не называется, но проистекает из тупой сишной семантики, типа отсуствия гигиенических макросов, нультерминированных строк, отсутствии алгебраических типов и так далее. И что в первом, что втором случае, нужно приложить достаточно усилий, чтобы очередной сишник заметил подвох.
>Дело не в характере ошибок, делов их в количестве. Не думаю, что общее количество ошибок на Расте меньше, чем в Си.Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.
> Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.Это было бы прекрасно, если бы не одно жирное "однако". Однако раст исключает (некоторые) ошибки управления памятью за счет драконовских, вообще говоря, ограничений боровчекера и ценой отказа от множества распространенных (проверенных, отработанных и удобных!) парадигм и техник программирования. Я не говорю уже о тормозах при компиляции из-за туевой хучи проверок и тому подобных неудобствах. Фокус в том, что это все вместе взятое вполне себе увеличивает вероятность появления ошибок остальных 100500 сортов, от которых раст не защищает.
>Однако раст исключает (некоторые) ошибки управления памятью за счет драконовских, вообще говоря, ограничений боровчекераПочему вы до сих пор не предложили не драконовские ограничения? Где соответствующая теория?
>ценой отказа от множества распространенных (проверенных, отработанных и удобных!) парадигм и техник программированияПрограмма должна быть корректной. Если вам так тяжело писать на rust, то почему бы не перейти на языки с gc, типа go или ocaml?
>Я не говорю уже о тормозах при компиляции из-за туевой хучи проверокКоторые вы придумали. Вот пример для крестов https://habr.com/ru/companies/jugru/articles/438260/ когда короткая программа расягивает компиляцию на несколько порядков. Осилите аналогичный пример для rust?
> Почему вы до сих пор не предложили не драконовские ограничения? Где соответствующая теория?О, пардон, я не в курсе что говорю практически с отцом-основателем. Так это вы придумали теорию типов? Снимаю шляпу. Скажите, а часовню -- тоже вы?...
> Программа должна быть корректной. Если вам так тяжело писать на rust, то почему бы не перейти на языки с gc, типа go или ocaml?
А почему бы вам, уважаемый, не перейти туда, куда обычно отправляют тех, кто указывает, кому на каком языке писать?
> Которые вы придумали. Вот пример для крестов
> Наследование реализации не в счёт, в Си его тоже нет.А что это вы, батенька, пример компиляции приводите для C++, а парадигмы решаете ограничить голыми Cями?
>А почему бы вам, уважаемый, не перейти туда, куда обычно отправляют тех, кто указывает, кому на каком языке писать?А почему бы вам не перестать портить память? Знаете, у меня нет ни малейшего желания ревьювить каждую программу, которая почему-то плохо работает, и тем более её переписывать.
>А что это вы, батенька, пример компиляции приводите для C++, а парадигмы решаете ограничить голыми Cями?Ну вот вам пример, какой бардак развели диды https://www.opennet.dev/opennews/art.shtml?num=56449 - Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%
И да, хочу сказать, что если язык проектируется нормально, то данная проблема в нём попросту невозможна
>Прирост производительности достигается за счёт изменения метода обработки заголовочных файлов. Отмечается, что за тридцать лет разработки ядра состояние заголовочных файлов приняло удручающий вид из-за наличия большого числа перекрёстных зависимостей между файлами.Ocaml, например, прямо ограничивает взаимозависимые модули.
Но сишники молодцы, они умудрились затормозить даже сравнительно быстрый си компилятор.
> А почему бы вам не перестать портить память?А я порчу? Надо же, не знал )))
> Ну вот вам пример, какой бардак развели диды https://www.opennet.dev/opennews/art.shtml?num=56449
А что, это патчи на каком-то другом C? Респект мужику, привел кодовую базу в порядок, молодец. А вот, первая ссылка в выдаче гугла, боль растофилов: https://users.rust-lang.org/t/is-rust-compile-time-really-th...
> А что, это патчи на каком-то другом C? Респект мужику, привел кодовую базу в порядок, молодец.Ну так мужику респект, а диды оказались бракоделами.
> А вот, первая ссылка в выдаче гугла, боль растофилов: https://users.rust-lang.org/t/is-rust-compile-time-really-th...
И? Это плата за проверки в компайл тайм. За вещи которые делает за тебя компилятор.
Которые делаются один раз, а потом запускаются у пользователей со скоростью сравнимой с с/с++.К сожалению чел не написал, что у него за железко, может он просто б0мж с коре2duo.
Вон у жабаскриптеров вообще компилять не нужно, может тебе в веб-камаки записаться)?
Можете привести распространённые парадигмы, от которых отказывается Rust? Наследование реализации не в счёт, в Си его тоже нет.
глобальные переменные?
доступ к разделяемым данным на запись для всех?
>Часть багов, которые могут случится на си созданы разработчиками си и называются UB.Неопределённое певедение возникает из-за особенности архитектуры компьютера. Язык Си тут не причём. Все ситуации, при которой может возникнуть неопределённое поведение описано во всех учебниках по языку Си, избежать их не трудно.
>Ещё часть багов никак не называется, но проистекает из тупой сишной семантики,
Из сишной семантики проистекtат только одна ситуация когда в операции сранения программист путает знак < == > со знаком < ==>. Других багов не знаю.
>типа отсуствия гигиенических макросов,
Я даже не знаю, что такое гигиенический макрос, и зачем он нужен.
>нультерминированных строк, отсутствии алгебраических типов и так далее.
Нуль-терминированные строки для относительно низкоуровневого языка нормальное явление. Компилятор не должен заниматься подсчётом строк. Алгебраический тип данных в таком языке как Си просто напросто не нужен. Алгебраический тип данных хорош для языков которые запускаются на виртуальной машине, как Python или Java, или же для мета-языка как C++
>И что в первом, что втором случае, нужно приложить достаточно усилий, чтобы очередной сишник заметил подвох.
Поверь мне чисто-сишнику не нужно прилагать никаких усилий. Надо быть просто внимательным.
Все беды сишников от элементарной невнимательности.>Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.
Сравнительного анализа общего количества ошибок в проектах где пишут на Си и Раст, ещё не проводилось. Для чистоты эксперимента должны браться проекты разработка которых началась в примерно в одно и то же время, и имеющих одинаковое количество строк кода. Раст появился недавно, а Си давно и поэтому критики языка Си так изгаляются.
>Все ситуации, при которой может возникнуть неопределённое поведение описано во всех учебниках по языку Си, избежать их не трудно.Такие ситуации должны избегаться автоматически. Почему программа с синтаксической ошибкой не собирается, а программа с UB - собирается?
>Из сишной семантики проистекtат только одна ситуация когда в операции сранения программист путает знакВ нормальных языках семантика сравнения и семантика присваивания различаются синтаксически. Вы их попросту не перепутаете.
>Я даже не знаю, что такое гигиенический макрос, и зачем он нужен.А поискать перед ответом в интернете слабо?
>Нуль-терминированные строки для относительно низкоуровневого языка нормальное явление.Ровно до тех пор, пока кто-то не попортит память.
>Алгебраический тип данных в таком языке как Си просто напросто не нужен.Вы там знаете
>Надо быть просто внимательным.Ну вы как просто вниметельный человек просмотрите весь код линукса, иксорга и прочих программ.
>и имеющих одинаковое количество строк кодаВы предлагаете специально раздувать код?
Посмотрите в сторону gcc -fanalyzer. с ним вполне себе ловятся много ошибок на C и не нужно вводить драконовские серы с борров чекером
> Неопределённое певедение возникает из-за особенности архитектуры компьютера. Язык Си тут не причём.Что за бред? Напомните, UB описаны в даташите на процессор или в стандарте Си?
UB это следствие нарушения инвариантов, заданных спецификацией языка, и никак иначе. Инварианты нарушает программист, а не компьютер.
Остальное даже не буду комментировать, типичная компетентность сишного иксперта.
> Инварианты нарушает программист, а не компьютер.А у вас одна реализация компьютера. Или все же больше...
?Так какая из них правильная, которую не надо нарушать?
> А у вас одна реализация компьютера. Или все же больше...
> Так какая из них правильная, которую не надо нарушать?Что вы собрались нарушать? Реализацию компьютера?
> Что вы собрались нарушать? Реализацию компьютера?Именно. Какую из реализаций взять за правильную, а какую нет?
Если вам разрешено нарушать реализацию компьютера - тогда я вам не советчик. Мне, как и другим смертным, это запрещено законами физики и здравого смысла.Если по делу, то вы путаете две вещи: спецификацию языка и его конкретную реализацию (компилятор). То, что вы пытаетесь мне доказать - почему был выбран именно такой набор инвариантов. А сделано это для того, чтобы в итоге генерировать эффективный ассемблерный код под разные архитектуры процессоров.
Ещё раз: инварианты задает спецификация языка, их связь с архитектурой компьютера косвенная и продиктованная желанием получить быстрый код.
> Если вам разрешено нарушать реализацию компьютера - тогда я вам не советчик. Мне, как и другим смертным, это запрещено законами физики и здравого смысла.Я спрашивал про какую из реализаций?
Их много. Что брать за правильное, а что нет?
> Ещё раз: инварианты задает спецификация языка, их связь с архитектурой компьютера косвенная и продиктованная желанием получить быстрый код.
И???
Какая из архитектур компьютера правильная а какая нет?
Ибо эта "косвенность" приводит к разному поведению программ. Что далеко не косвенно.
> Я спрашивал про какую из реализаций?
> Их много. Что брать за правильное, а что нет?
> Какая из архитектур компьютера правильная а какая нет?Перестаньте задавать один и тот же глупый вопрос. Стандарт языка Си описывает поведение программ для абстрактной модели вычислителя, а не для конкретной аппаратной архитектуры.
> Ибо эта "косвенность" приводит к разному поведению программ. Что далеко не косвенно.
Нет, не приводит. Если у программы разное поведение, то возможны два варианта:
1. она содержит implementation-defined behavior или unspecified behavior и такое поведение ожидаемо и предусмотрено автором.
2. она содержит undefined behavior (некорректна с точки зрения стандарта) и должна быть исправлена.
> Кто пишет на чистом Си, и реально желает избежать багов, тот их избежит. Вина в не внимательности и торопливости.Опять настоящих сишников ищет. Посмотри под юбками настоящих шотладнцев, может они там прячутся.
>Если я в программе на C сделаю баг как на расте -- можно?Если матёрые сишники с этим не справляются, то почему вы должны?
>Короче, можно полную инструкцию, какими должны быть правильные баги?Давайте. Как минимум без выхода за границы массива, двойного освобождения, висячих указателей, чтения нулевых указателей.
>Давайте. Как минимум без выхода за границы массиваНе получится. Потому-что подсчётом размера массива занимается сам программист. Растаманам задницу всё время подтирает компилятор, а это плохо. Сишник самостоятелен, растаман нет.
Это Сишник-то самостоятелен? Настоящая самостоятельность - программирование на ассемблере. Вот там да, полная свобода манипулированием данными
И ты, конечно, сейчас расскажешь, что такое можно сделать на Асме, но нельзя на Си?
Не, ребят, сегодня не ваш день. Сначала предатели, пардон, производители процессоров вместе с Линусом в спину ударили, а теперь - вот))
Можно подробнее, пожалуйста?
> Можно подробнее, пожалуйста?
Спасибо.
Так и не ваш тоже opennet.ru/opennews/art.shtml?num=64092
Вы же не будете сравнивать какую-то либу с ядром.ЗЫ: а чего в ту тему не заглянули, проффесор? сказать нечего было?
> Так и не ваш тоже opennet.ru/opennews/art.shtml?num=64092
> Вы же не будете сравнивать какую-то либу с ядром.Спасибо, посмеялся)) Не, не поможет ;)
> ЗЫ: а чего в ту тему не заглянули, проффесор? сказать нечего было?
Потроллить на сон грядущий ;) Не всё ж вам развлекаться))
> Спасибо, посмеялся)) Не, не поможет ;)Конечно не поможет.
Если человек ставит в один ряд ядро линукс и какую-то либу от дилетантов.. то это многое о нем говорит)> Потроллить на сон грядущий
Получилось весьма уныло.
Может лучше про коммунизм? Та щиза хотя бы веселее звучит!
> Конечно не поможет.
> Если человек ставит в один ряд ядро линукс и какую-то либу от
> дилетантов.. то это многое о нем говорит)Снова посмеялся)) Не пытайтесь вырулить, говорю ж - не поможет)) Вам производители процессоров такую свинью подложили, прям загляденье.
>> Потроллить на сон грядущий
> Получилось весьма уныло.Но вы ж стриггерились - значит уже нормально ;)
>Не, ребят, сегодня не ваш деньСказал человек неосиливший xml парсер. От вас так и веет некомпетентностью.
> Сказал человек неосиливший xml парсер. От вас так и веет некомпетентностью.И это всё? Кроме унылых попыток перейти на личности больше уже ничего не осталось? Ни высосанных из пальца примеров кода? Ни набросов про undefined behavior?)) Совсем-совсем ничего? Да-а-а... Мельчает тролль)) Может вам пора другую работу поискать? Пока возможность есть? Поучиться там чему? Вопросы, если что - риторические, чисто вам на заметку.
>И это всё? Кроме унылых попыток перейти на личности больше уже ничего не осталось?Как говорится
>Talk is cheap. Show me the code.Вы свой код уже показали, ваш уровень не дотягивает даже до студента.
>>И это всё? Кроме унылых попыток перейти на личности больше уже ничего не осталось?
> Как говорится
>>Talk is cheap. Show me the code.
> Вы свой код уже показали, ваш уровень не дотягивает даже до студента.Да без проблем)) Только при чём здесь я? Речь то пров вас идёт, господа. В общем, попытка съехать с темы не засчитана ;)
> Вы свой код уже показали, ваш уровень не дотягивает даже до студента.Свой код покажешь, тогда и оценки будешь раздавать. А пока не дотягиваешь, чтобы мнение иметь.
Оценить вкус торта может только повар!И пафосно колпак на затылок сдвинуть.
Уровень демагогии у вас очень низок. Прямо начальный.
> производители процессоровТак в АРМ такая проверка уже давно есть.
Но раст в Андроид внедряют.Если проверка такая крутая, то почему она не помогает))?
> Так в АРМ такая проверка уже давно есть.
> Но раст в Андроид внедряют.
> Если проверка такая крутая, то почему она не помогает))?Так это вы в Google спрашивайте, кого они там нанимают и как обучают, что им уже ничего не помогает.
Да, ребята, людей нужно нормально учить, других вариантов нет. Бесплатно учить. Ни "волшебные" ЯП, ни искусственный интеллект (который искусственный - да, но вот интеллект - нет) вам не помогут. Придётся прибылью делиться со всеми.
Ой, как будто кто-то сейчас пользуется таким древним овном как TAR?
Оно появилось более 40 лет назад.
> Ой, как будто кто-то сейчас пользуется таким древним овном как TAR?
> Оно появилось более 40 лет назад.Архивы кода по умолчанию с GitHub в tar.gz отдаются))
> Архивы кода по умолчанию с GitHub в tar.gz отдаются))Эм... нет, это вы у себя что-то нахимичили с настройками. По умолчанию отдается zip.
github.com/torvalds/linux
Download ZIPПроверьте сами.
Раст обделался с перепмсыванием, значит, tar ненужен! Л - логика.
Сишникам совсем уже делать нечего. Нашли микроскопическую ошибку и раздули из этого целую "уязвимость".
Удалите новость, опеннет, не позорьтесь.
Нееет, выделите новость 20-м шрифтом.
Чтобы все оценили "кекспертизу" обсуждающих её сишников
>Удалите новость, опеннетОни и сайтам указывают.
Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...
>Почему программисты на Rust не могут <буквально> переписать логику с реализацией на CПотому, что тогда у них будут буквально те же самые дыры, что и на си. Ибо на си нет афинных типов данных.
И что, без аффинных типов в безопасном коде на Rust будут дыры? Вот это новость!
скиньте кто-нить этому умнику линк на словарь Ожеговаа то от его "афинных" типов у меня скоро глаз дергаться начнет
услышал где-то умное слово и носится с ним, как дурень с писаной торбой
>услышал где-то умное словоТак я хочу, чтобы вы тоже услышали, а вы уши затыкаете. Ну и узнали что это такое.
если б ты его еще писал правильно цены б тебе не быловсе эти "афинные" типы много помогли, когда прошлым летом выяснилось, что много лет назад в std::process::Command налажали с эскейпингом аргументов и все эти годы имели выполнение в шелле произвольной программы. как первокурсник-башпортянщик.
SUCH SAFE. MUCH SECURITY.
А теперь скажи: какие это "правила эскейпинга" существуют на винде, где аргументы идут одной сплошной строкой
Ведь именно на винде этот баг и был, на Unix всегда всё хорошо с этим было
> А теперь скажи: какие это "правила эскейпинга" существуют на винде, где аргументы
> идут одной сплошной строкой
> Ведь именно на винде этот баг и был, на Unix всегда всё
> хорошо с этим былотебе надо - ты и уточняй. мне делать больше нечего кроме гуглить за всякого.
но вспомнил, вижу, что вспомнил. давай, объясни, что вин онли cve - ЭТАДРУГОЕ
> тебе надо - ты и уточняй. мне делать больше нечего кроме гуглить за всякого.В том и дело что их нет, в лучшем случае несколько разных конвенций
Баг из CVE исправляется особой проверкой аргументов, если команда - cmd.exe, и первый аргумент ей передаваемый - /c, в остальных случаях логика остаётся той же самой.
При этом в других языках (даже C#) это просто ошибкой не считается, просто "особое виндовое поведение, хотите дёргать команды - изучайте как винда это обработает"
http://blogs.msdn.com/b/twistylittlepassagesallalike/archive... (открывать через вебархив)
https://weblogs.asp.net/jongalloway/_5B002E00_NET-Gotcha_5D0.../
> При этом в других языках (даже C#) это просто ошибкой не считается,
> просто "особое виндовое поведение, хотите дёргать команды - изучайте как винда
> это обработает"што за чушь ты мне втираешь?
CVE в системной либе "ошибкой не считается"?
нууу ОК.
> CVE в системной либе "ошибкой не считается"?Эта же самая ошибка содержится во многих других языках (node.js, .net), при этом там ошибкой не считается, и не имеет CVE
Скор 10.0 установлен репортером CVE (github в данном случае), а не NVD: https://nvd.nist.gov/vuln/detail/cve-2024-24576
>> CVE в системной либе "ошибкой не считается"?
> Эта же самая ошибка содержится во многих других языках (node.js, .net), при
> этом там ошибкой не считается, и не имеет CVE
> Скор 10.0 установлен репортером CVE (github в данном случае), а не NVD:
> https://nvd.nist.gov/vuln/detail/cve-2024-24576дачточертпоберитакоетынесешь.джпг
баг из стандартной библиотеке rust присутствует в node.js, ага. и в дотнете.
пиши уже сразу "в си и бейсике тож", чтоп два раза не вставать.
> дачточертпоберитакоетынесешь.джпг
> баг из стандартной библиотеке rust присутствует в node.js, ага. и в дотнете.
> пиши уже сразу "в си и бейсике тож", чтоп два раза не
> вставать.Стандартная библиотека Rust, как и стандартные библиотеки многих других языков, позволяет спавнить процессы передавая аргументы для процесса как массив
Винда такое не умеет, в винде аргументы процесса это просто строка, поэтому для винды эти аргументы надо заэскейпить и превратить в строку
Правил эскейпинга нет, и факт в том что эту строку аргументов некоторые программы обрабатывают иначе чем другие. В Rust для обеспечения безопасности сделали другую форму эскейпинга для аргументов команды cmd.exe, при этом в реализации была ошибка, из-за чего была возможна инъекция команд в cmd.exe, и на это завели CVE.
Однако факт в том что большинство других рантаймов вовсе не имеют иной обработки эскейпов для cmd.exe, там просто всё отдали под ответственность разработчика, они просто допускают в данном случае инъекцию, и при этом не считают это багом или уязвимостью
И да, в си та же самая проблема если ты будешь использовать POSIX spawn() под виндой, оно тоже некорректно превращает массив аргументов в строку для CreateProcess, о чём прямо сказано в доках винды: https://learn.microsoft.com/en-us/cpp/c-runtime-library/spaw...
Do not pass user input to _spawn without explicitly checking its content. _spawn will result in a call to CreateProcess so keep in mind that unqualified path names could lead to potential security vulnerabilities.
...тогда судите сразу и за изнасилование. а чо, аппарат-то есть...
> ...тогда судите сразу и за изнасилование. а чо, аппарат-то есть...Ну вот Rust судили, Rust согласились что это неправильно, и потому завели CVE
Все другие сказали что не баг, а фича, и CVE не было
Большинство растеров сами не понимают, что это такое -- афинные типы. Но как звучит! Афинные! Греция, оливки, голые рабы на аренах... Они и бегут, пуская слюни и oбляпaвшись смyзи.
>Большинство растеров сами не понимают, что это такое -- афинные типыТак я не на расте пишу, а вот сишников троллить - одно удовольствие.
>голые рабы на аренахВ Древней Греции рабов на арену не пускали. На арене были атлеты, свободные граждане. Ну да в голом виде, без трусов. Просто нижнего белья как трусы тогда не знали.
> Афинные! Греция, оливки, голые рабы на аренах...Историк по образованию затесался на опеннет? У любого технаря первой ассоциацией со словом "афинные" будут "афинные преобразования" из геометрии первого курса.
> Большинство растеров сами не понимают, что это такое -- афинные типы. Но как звучит!Это геометрический термин. В Расте означает натягивание совы на глобус.
> Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...В основном они этим и занимаются, но специфика концепции владения в расте такова, что это не всегда возможно, боровчекер не велит. Ну и код они читать не особо привыкли, "компилируется --- значит, работает", вот их девиз.
Кампания популяризации Rust от корпораций как раз нужна им, чтобы набить кодовую базу для "ИИ", а потом "ИИ" всё будет писать сам. Им для "ИИ" нужен был язык, где нет "утечек" по умолчанию. (хотя это спорно). В итоге в будущем много софта будет AI slop написанным на Rust
> Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...Ну так да, язык рассчитан на то, что человек не может сам нормальный код написать. ВОт только какие-то ошибки он может и отловит, а дальше беда
Не ошибается тот, кто ничего не делает. Давайте зароем топор войны Rust и C!
Вместе с ростом xd
Rust вообще как язык ничего. Растодрочерство бесит, как любая секта.
Ну или проще, хвали свое, но не надо хаять чужое.
Кек.>найден баг в софте на си
растеры: ахаха, фуу, диды, шерето, дырявое, закопать!
>найден баг в софте на расте
растеры: не надо судить так строго, и вообще давайте забудем старую вражду, какое мы вам плохое зло сделали, да и вообще это не баг а фича
Нельзя так просто зарыть топор войны с Rust-ом. Сперва нужно понять, кто им владеет. А потом передать его владение земле.
Очередные неосиляторы юнит тестов. Попросили бы ИИ написать, даже самим не надо париться.
V in vibrant community means CVE
Сама суть unit тестов в том, что ты их сам пишешь осознанно, и не доверяешь "ИИ" с его галлюцинациями.
Обычная логическая ошибка. Сам Rust не причём.
Ну, в языке C выход за границы массива и "use after free" - это тоже обычные логические ошибки. Сам C не причем.
> Ну, в языке C выход за границы массива и "use after free" - это тоже обычные логические ошибки.Это когда приводят int к uint, получают переполнение с UB?
Что-то логикой тут не пахнет))
> int к uintЯП в котором этого нельзя сделать (ао многих вообще unsigned типов нет) - низкоскоростные помойки, т.к. например так можно хакнуть приведение числа в диапазон 0..X, если исходный int мог быть отрицательным - unsigned достаточно проверить только на < X, проверка > 0 уже не нужна. В компутор вижн такое полезно.
> ЯП в котором этого нельзя сделать (ао многих вообще unsigned типов нет) - низкоскоростные помойки,Угу, а у нас высокоскоростная помойка)
> т.к. например так можно хакнуть приведение числа в диапазон 0..X, если исходный int мог быть отрицательным - unsigned достаточно проверить только на < X, проверка > 0 уже не нужна.
И получить выстрел в ногу.
> В компутор вижн такое полезно.
Уязвимости из-за хаков и костылей? Сомнительно.
Но даже так, каст может быть явный, где программер делает осознанное действие, а может быть как в недоязычках.
Вот из недавнего "Уязвимости в библиотеке libxml2"
opennet.ru/opennews/art.shtml?num=63431Какой-то ге(й)ний решил использовать для size переменную signed.
В функции ̶п̶р̶о̶и̶з̶о̶ш̶л̶а̶ ̶ч̶у̶д̶о̶в̶и̶щ̶н̶а̶я̶ ̶о̶ш̶и̶б̶к̶а̶ случился неявный каст signed в unsigned size_t.
Вам дырень, получите и распишитесь.
> Какой-то ге(й)ний решил использовать для size переменную signed.Во многих языках unsigned вообще нет, жабка, питон, и т.д.
> как в недоязычках ... Уязвимости в библиотеке libxml2
Ну так пускай прекрасные питон эльфы напишут свою безопасную либу для парсинга, подумаешь, всего-то в 100 раз медленнее будет работать.
> Во многих языках unsigned вообще нет, жабка, питон, и т.д.Так это норм. Есть известные ограничения, которые определяют сферу применения.
Не норм когда один и тот же код начинает работать непредсказуем.> Ну так пускай прекрасные питон эльфы напишут свою безопасную либу для парсинга, подумаешь, всего-то в 100 раз медленнее будет работать.
Так тебе важнее скорость или отсутствие подобных сюрпризов)?
Может у гугла или амазона дойдут руки и они наймут растовиков.
Вон Биндер переписали - получилось надежнее чем на СИ и скорость не пострадала.
> Так тебе важнее скоростьМне незачем трястись над безопасностью, практически везде где я работал - софт или не открывал никаких пользовательских файлов, или делал это используя либы из ОС (андроид) изменить которые не представляется возможным, а тащить с собой их "безопасные" аналоги из-за параноидальных опасений попросту глупо, часто невозможно (для видеофайлов в 4к - сторонняя либа декодирования, не полагающаяся на аппаратное ускорение через механизмы ОС попросту сядет в лужу) да и вообще всем плевать. А баги - любой коммерческий разработчик знает, что их на любом ЯП в проекте будет предостаточно. А вот скорость важна.
> Мне незачем трястись над безопасностью, практически везде где я работал - софт или не открывал никаких пользовательских файлов,Браузер там был?
"Критическая 0-day уязвимость в Chrome и libwebp, эксплуатируемая через изображения WebP"
opennet.ru/opennews/art.shtml?num=59746
"0-day уязвимость в Chrome и libvpx, затрагивающая кодировщик видео VP8"
opennet.ru/opennews/art.shtml?num=59838
Позволяют выполнить свой код при открытии специально оформленной web-страницы или изображения. На момент исправления в сети уже были эксплойты.> или делал это используя либы из ОС (андроид) изменить которые не представляется возможным,
Но ты был бы не против, если либы "по умолчанию" будут написаны без подобной лажи?
> а тащить с собой их "безопасные" аналоги из-за параноидальных опасений попросту глупо, часто невозможноЕсли этим не занимаются намеренно, например разработчики ОС.
> баги - любой коммерческий разработчик знает, что их на любом ЯП в проекте будет предостаточно. А вот скорость важна.
Баг-багу рознь.
Если где-то верстка сьехала или кнопочки не того цвета, то терпимо, можно кинуть в беклог.
Если теряются пользовательские данные - то это критика и все сидят и исправляют.
Если, не дай бог-машина, утечка пользовательских данных - то можно попасть на GPDR и похоронить проект.
> Ну, в языке C выход за границы массива и "use after free"
> - это тоже обычные логические ошибки. Сам C не причем.Нет. Это неопределённое поведение.
Неопределенное поведение - это уже результат таких ошибок.
> Неопределенное поведение - это уже результат таких ошибок.Ага. Поэтому C плох.
Есть три варианта решения проблем множества архитектур.1. Сказать что в общем случае все архитектуры ответят одинаково, в частных могут быть различия (неопределенное поведение).
2. Реализовать свою среду выполнения полностью.
3. Делать вид что поддерживаешь множество архитектур. По-крайней мере собираешься. Реально реализовать одну и надеяться что все остальные сдохнут. А когда нужда заставляет показатель реальную поддержку, делать отладочную версию с полной реализацией среды выполнения и рабочую с неопределённым поведением.
Сдаётся мне, что с третьим путем далеко не уедешь.
>>вызвана некорректным выбором позиции в потокеНужно срочно изобрести язык, который защищает от некорректношо выбора позиции в потоке и всё ПО переписать на него.
Может проблема вообще в tar? С какого перепугу архив внутри архива воспринимается как продолжение одного?
> Может проблема вообще в tar? С какого перепугу архив внутри архива воспринимается как продолжение одного?Чего уж там, если мир не подходит для раст -- нафиг такой мир. Всё должно быть таким, чтобы если скомпилировалось на раст -- значит работает. Эврика, я придумал, как писать абсолютно безглючные программы!
У тара куча проблем, например невозможность быстрого просмотра индекса, но к новости они отношения не имеют.
То-то еще будет. Когда helloworld ваять на расте - там особых и мозгов то не надо. За 3 недели в любом рекламирующемся "factory".. до недопрограммиста!
Господа сишники, объясните мне, зачем вам нужна возможность разыменновывать null, и зачем вам нужны негигиенические макросы?
Сначала попробуй на низком уровне поработать с памятью, а потом глупости будешь спрашивать.
Хотя разыменовывать null - это тоже глупость. У дурачков зачастую функция возвращает указатель на данные и в какой-нибудь очень "плохой день", когда вдруг памяти не хватило (зачем это предусматривать - любой современный комп имеет ее вагон и маленькую тележку), или еще что-нибудь вдруг возвращает null. Дурачек есстественно не проверяет сам указатель, а пытается его содержимое проверить на что-нибудь if(*lp .... ). Вот тебе и разыменовывание. Это недостаток мозгов. Так как в данном случае нужны 2 проверки, но дурачек об этом не знает.
>Хотя разыменовывать null - это тоже глупость.Удивительно, вы это признаёте.
>Так как в данном случае нужны 2 проверки, но дурачек об этом не знает.То есть разделить указатели на два типа - точно не null и возможно null - и запретить разыменновывать те, которые возможно null - слишком сложно для сишников? Почему даже такая простая вещь до сих пор не встроена в компилятор?
>>Хотя разыменовывать null - это тоже глупость.
> Удивительно, вы это признаёте.
>>Так как в данном случае нужны 2 проверки, но дурачек об этом не знает.
> То есть разделить указатели на два типа - точно не null и
> возможно null - и запретить разыменновывать те, которые возможно null -
> слишком сложно для сишников? Почему даже такая простая вещь до сих
> пор не встроена в компилятор?Эти сишники такие-же как и растовики. 3 месяца тупого образования. Правда за растовиками обычно компилятор гамно прибирает.
Сишники которые проблему знают и представляют - таких ошибок не делают.
> Эти сишники такие-же как и растовики. 3 месяца тупого образования. Правда за растовиками обычно компилятор гамно прибирает.Т.е автоматизация, как любят программисты.
> Сишники которые проблему знают и представляют - таких ошибок не делают.
А ж где таких взять? Чтобы клонировать)
Но судя по тому, что ты написал, выходит "если взять рандомных сишников и растовиков, то от последних овна будет меньше, тк компилятор поубирал".
>> Эти сишники такие-же как и растовики. 3 месяца тупого образования. Правда за растовиками обычно компилятор гамно прибирает.
> Но судя по тому, что ты написал, выходит "если взять рандомных сишников
> и растовиков, то от последних овна будет меньше, тк компилятор поубирал".Толку от них будет напорядок меньше. Так как если человек с Си связывается - он хотя-бы математический класс закончил. И базовые алгоритмы программирования знает, хотя и опыта ему не хватает. Но через определенное время он натренируется.
Rust же - это залетные -"Ой, в IT платят хорошо". толку от них не будет даже в дальней перспективе, так как rust сдохнет в угоду еще чему нибудь.
> Толку от них будет напорядок меньше.Хм.. чего тогда в соседней теме сложную и важную штуку в ядре заменяют?
> Так как если человек с Си связывается - он хотя-бы математический класс закончил. И базовые алгоритмы программирования знает, хотя и опыта ему не хватает.
Звучит как-то притянуто за уши.
Что мешает уйти в СИшку самоучке вообще без образование.> Но через определенное время он натренируется.
Практика показывает что нет.
Тут уже приводили пример Теодора Тцо, который вроде пишет в ядро с 91 года, а ошибки допускает как первокурсник.> Rust же - это залетные -"Ой, в IT платят хорошо". толку от них не будет даже в дальней перспективе, так как rust сдохнет в угоду еще чему нибудь.
Тут ты уже в фантазии ушел.
Народ который пишет на расте, зачастую пришли с сишки или плюсов.
Т.к для других задач есть более удобные ЯП со сборщиком мусора.
>> Толку от них будет напорядок меньше.
> Хм.. чего тогда в соседней теме сложную и важную штуку в ядре
> заменяют?ТОлько во "влажных мечтах" недопрограммистов там "важную штуку в ядре заменяют". И в данном случае я считаю Торвальдса кретином, так как он тупо не понял в чем преймущество плюсов. Хотя для MacOS/iPhoneOS objectiveC/C++ используются повсеместно, с уровнем безопасности не хуже ржи... Да и в BSD нет прямого запрета на использование C++ в ядре.
> ТОлько во "влажных мечтах" недопрограммистов там "важную штуку в ядре заменяют".Хочешь сказать что биндер-драйвер для миллионов андроид устройств, это так, мелочь)?
Ну ок, ты наверное ракеты к звездам запускаешь, раз такое пренебрежение.
>> ТОлько во "влажных мечтах" недопрограммистов там "важную штуку в ядре заменяют".
> Хочешь сказать что биндер-драйвер для миллионов андроид устройств, это так, мелочь)?
> Ну ок, ты наверное ракеты к звездам запускаешь, раз такое пренебрежение.Биндер-Драйвер... Мдеее.. поржал.
> Биндер-Драйвер... Мдеее.. поржал.Смех без причины признак...
Просто открываем репозиторий ядра
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eafedbc7c050И просто читаем 'add Rust Binder driver'
Я понимаю, что ты настолько круче разрабов ядра, что ржешь целыми днями.
Но свой уровень компетенции показал отлично.
Ну да, в ядро в целом Растовиков не пустили, поджопник выписали, так они полезли через Окно - "InterProcessCommunication".
Смешно еще больше.
> Ну да, в ядро в целом Растовиков не пустили, поджопник выписалиЧто значит не пустили? Они наоборот получили полный картбланш от Торвальдса и Грега.
А сишным разрабам позатыкали рты и замерджили код в обход мейнтейнера, который потом вообще ушел. Не нужно тут всех пытаться успокоить, что типа "все нормально, сколько там того раста".> так они полезли через Окно - "InterProcessCommunication".
Эти кода в ядре - в ядре.
В мейнлайне - в мейнлайне.
Вот и всё.Но кроме него уже в мейнлайне - drivers/gpu/nova-core и drivers/gpu/drm/nova, QT2025, ASIX AX887xx. Кроме них outside mainline - Apple AGX, ashmem, NVMe driver.
И готов поставить десятку что их тоже впихают в ядро.PS: вот из-за таких как ты, которые говорят "ой, да что там тот раст", раст в ядро так легко и впихнули.
> И в данном случае я считаю Торвальдса кретином, так как он тупо не понял в чем преймущество плюсов.Рукоплещу стоя! Полностью согласен. Дополню: BeOS|Haiku целиком на плюсах -- и ни разу от этого не плачут, а Хайку еще и летает шустрее.
> Рукоплещу стоя! Полностью согласен.Ого, да тут сход анонимных критиков Торвальдса.
Бедняга наверное икает))> Дополню: BeOS|Haiku целиком на плюсах -- и ни разу от этого не плачут, а Хайку еще и летает шустрее.
Что то ****, что это (с) Эскобар Теоремный
И какая распространенность у перечисленных ненужностей?
> И какая распространенность у перечисленных ненужностей?Распространнёность уже отражает надёжность, производительность? x86 вон тоже костыль по сравнению с некоторыми другими архитектурами древности, однако ж взлетело.
> Распространнёность уже отражает надёжность, производительность?Производительность - да и нет.
Тесты и бенчи понятно покажут кто круче, а вот оптимизации будут в первую очередь делать для распространенного.Надежность - да.
Т.к распространенное будут ковырять в первую очередь.Немного перефразирую: "нет программ без багов, есть недообследованные"
>> Rust же - это залетные -"Ой, в IT платят хорошо". толку от них не будет даже в дальней перспективе, так как rust сдохнет в угоду еще чему нибудь.
> Тут ты уже в фантазии ушел.
> Народ который пишет на расте, зачастую пришли с сишки или плюсов.
> Т.к для других задач естьОткровенный бред нести не надо. Никто с С, а тем более с плюсов на Rust не пойдет (кроме пары процентов совсем отмороженых). Особенно для разработки backend-а, а для frontend-а, ты сам написал - "есть более удобные ЯП со сборщиком мусора." Тот же GO например.
> Откровенный бред нести не надо. Никто с С, а тем более с плюсов на Rust не пойдет (кроме пары процентов совсем отмороженых)."Бред" это ты сам выдумал?
ТОРом пользуешься? Ну так вот создатели ТОР-клиента сами решили создать Arti на замену сишному.
Клоудфларя, амазон, мелкомягкие.. там тоже отмороженные?
Гугл в конце концов: они переводят команды С/C++ на раст.> Особенно для разработки backend-а,
Именно для разработки бекенда.
Если нужны хотя бы какие-то гарантии, а в ультра ограниченную МИСРУ лезть не хочется, а до АДЫ еще не доросли процессы.> а для frontend-а, ты сам написал - "есть более удобные ЯП со сборщиком мусора." Тот же GO например.
Да. Поэтому растом могут заинтересоваться только системщики, которые до его появления довольствовались убогим СИ.
>Откровенный бред нести не надо. Никто с С, а тем более с плюсов на Rust не пойдетПрямо рядом соседняя новость
В ядро Linux 6.18 принята реализация Binder IPC для Android, написанная на Rust - https://www.opennet.dev/opennews/art.shtml?num=64092#118
>Реализация Binder на Rust аналогична по функциональности с изначальным вариантом на языке Си, проходит все тесты AOSP (Android Open-Source Project) и может использоваться для создания рабочих редакций Android-прошивок. Несмотря на продвинутые возможности и поддержку объектов со сложной семантикой владения, драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода.
>>Откровенный бред нести не надо. Никто с С, а тем более с плюсов на Rust не пойдет
> Прямо рядом соседняя новость
> В ядро Linux 6.18 принята реализация Binder IPC для Android, написанная на
> Rust - https://www.opennet.dev/opennews/art.shtml?num=64092#118
>>Реализация Binder на Rust аналогична по функциональности с изначальным вариантом на языке Си, проходит все тесты AOSP (Android Open-Source Project) и может использоваться для создания рабочих редакций Android-прошивок. Несмотря на продвинутые возможности и поддержку объектов со сложной семантикой владения, драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода.Я же тебя предупреждал - не делай из себя клоуна.
IPC это InterProcessCommunication. К ядру он имеет весьма опосредованное отношение и работать будет абсолютно по другому. С издержками на передачу данных и т.д.
То-то я думаю что последние Андроед помойку напоминают, из которой мусор уже как 2 редакции не вывозили.
Выбирать Rust первым языком для вката в IT никто не будет, там, думаю, питонисты лидируют с большим отрывом (поскольку самый тупой язык). А вот перебежчиков на Rust с Си и C++ наблюдаю сотнями (это буквально: пообщался с народом на Rust-конференции).
>Сишники которые проблему знают и представляют - таких ошибок не делают.Эти мифические сишники, пишущие код без багов. А вот открываешь список изменений в новой версии, и там всё как всегда. Потому, что недостаточно об этом помнить, нужно проверять каждый указатель и крайне желательно делать это автоматически.
Потому что указатель это не некая магическая сущность, а просто целое число, содержащее адрес байта в памяти (виртуальной а бывает и физической). Осознай это и многое станет понятнее.
> Потому что указатель это не некая магическая сущность, а просто целое число, содержащее адрес байта в памяти (виртуальной а бывает и физической).Только если вы пишете на ассемблере. С точки зрения оптимизирующего компилятора, помимо адреса указатель содержит информацию о своём происхождении (origin). Нарушение правил aliasing'а ведёт к неопределённому поведению. Поэтому да, указатель - вполне магическая сущность.
> Осознай это и многое станет понятнее.
Вряд ли. Типичный сишник стандарт не читает, либо сознательно его нарушает, плодя UB.
Много поделий на Си перестанут работать, если это станет обязательным:
opennet.ru/opennews/art.shtml?num=64091
> Много поделий на Си перестанут работать, если это станет обязательнымНе перестанет. Большинство сишных программ не просто важны, незаменимы. Они получат больше внимания, и ошибки быстро поправят.
А вот самые настоящие "поделия", на Расте которые, станут ещё более не нужны. Это факт.
На ассемблере вообще указатели не нужны. Они на железном уровне реализованы.
Всё правильно выше сказали.
Потому что ассемблер так умеет, почему бы и сишке не уметь? А зачем тебе нужна возможность молотком себе по яйцам бить?
>зачем вам нужна возможность разыменновывать nullПотому что в железе нет никакого специального значения null, это как правило адрес 0x0. И это совершенно валидный адрес. На некоторых платформах (DOS, например) его нужно рызыменовывать, там начало таблицы ISR.
Никто не мешает тебе написать ОС, у которой по адресу 0x0 будут находиться какие-то вполне легальные данные.
>>зачем вам нужна возможность разыменновывать null
> Потому что в железе нет никакого специального значения null, это как правило
> адрес 0x0. И это совершенно валидный адрес. На некоторых платформах (DOS,
> например) его нужно рызыменовывать, там начало таблицы ISR.
> Никто не мешает тебе написать ОС, у которой по адресу 0x0 будут
> находиться какие-то вполне легальные данные.Осью это обычно не ограничивается. RESET традиционно начинает с 0го адреса, если принудительно не задано иное. И там будет код jmp или реально исполнимый код. А эту область памяти - код, трогать очень нежелательно. Ну и да, таблицы прерываний - хотя они так-же могут быть перенесены куда-то. Но это не делают. Всем проще считать адрес прерывания 0+
>Осью это обычно не ограничивается. RESET традиционно начинает с 0го адреса, если принудительно не задано иное.Отлично, у нас есть уже какой-то проблеск сознания. А теперь расскажите мне, зачем это нужно в любом более менее прикладном софте? И почему в си это UB, как же тогда прерывания считывать?
ЗЫ я так понимаю, про негигиенические макросы ответа можно уже и не ждать?
Не UB, а implementation defined поскольку архитектуры (сюрприз) бывают разные.
>> И почему в си это UB, как же тогда прерывания считывать?
> Не UB, а implementation defined поскольку архитектуры (сюрприз) бывают разные.Согласно стандарту С разыменование нулевого указателя - это именно UB.
Потому и UB, что для DOS/x86 real mode это допустимо, для ядра linux/windows допустимо (прикинь, да?), да, а для несистемного процесса внутри этих ОС принято считать недопустимым, потому что memory allocator внезапно может отказать в выделении 1 ТБ памяти (кек, посмотри как хромог в htop показывается).Завершать программу аварийно? Orly? Нет, программа сама решает свои проблемы. Значит нужно как то ошибку вернуть, и предусмотреть наказание за её необработку.
Придумайте другую модель управления памятью?
>почему в си это UBА почему в си это UB?
>негигиенические макросы
Это фича, никто ее менять не будет. Видно, что вы не пишете на С, раз задаете такие вопросы.
Если добавлять гигиенические макросы, то они должны быть отдельной сущностью, не те которые #define.
Хотите такие макросы и запрет разыменования null - сделайте прототип нового С. Судя по тому что вы пишете, вам это будет несложно. Если это будет интересно сообществу - вас на руках будут носить.
>>почему в си это UB
> А почему в си это UB?Потому, что это черным по белому написано в стандарте.
> запрет разыменования null - сделайте прототип нового С
А зачем новый, если и в старом это изначально запрещено стандартом?
Потому что похоже, что ваше понимание UB это "ХЗ что получится, random какой то", а стандарт считает что это "implementation defined" то есть зависит от целевой системы, и в стандарте этого нельзя определить.
В DOS/x86 по адресу 0 вполне реальные данные, потому что Intel так сказал.
И null pointer много крови попортил.
По крайней мере на x86 RESET НЕ НАЧИНАЕТСЯ с адреса 0, это вас кто-то обманул.
Любопытная новость, спасибо. Хороший пример ошибки, которую может совершить программист независимо от используемого языка.Полагаю, если Rust продолжат форсить по прежнему, мы увидим ещё не один и не два подобных примера.
Да, это скорее внешний признак, который говорит о том, что раст получает все большее распространение.
Обратите внимание на этот проект: https://github.com/nushell/nushellСкоро на всех экранах мира, как говорится.
Да брось! Ни малейшего шанса! :)Такого уже было ... и так же пугали мол вот ОНО! Да хоть fish тоД-же :)
Будет установлен у 1% ... у тех, которые из 4% ;-DDDDD
Толку от него, если он будет только у тебя на локахосте?
А так было ясно изначально, природа не терпит пустоты. Уйдут ошибки работы с памятью на их место придут логические ошибки, и общее число ошибок будет прежним.
И вот уже на безопасном языке, небезопасная библиотека.
> А так было ясно изначально, природа не терпит пустоты.Когда фраза начинается с "сразу было понятно", то сдается меня хотят обмануть.
> Уйдут ошибки работы с памятью на их место придут логические ошибки, и общее число ошибок будет прежним.
А вот это просто пальцем в лужу.
Никаких доказательств.
> природа не терпит пустоты. Уйдут ошибки работы с памятью на их место придут логические ошибки, и общее число ошибок будет прежнимЛ - логика... Или это (не очень) тонкая ирония? "Щютка юмара"?
Кексперты всерьёз утверждают, что в их сишном коде _только_ ошибки работы с памятью, а "логических" нет? Первый тип ошибок исключает второй? А вот как только избавятся от первых, так сразу откуда-то польются вторые, заполнять пустоту? Сишные сумрачные гении не могут без ошибок? Если у них отберут первые ошибки, они что, специально начнут плодить вторые?
Почему сразу сишные, а не пэхапэшные например? Языков в которых реализована безопасная работа с памятью хоть жопой жри. Толку от этого...ну вот первая ласточка уже прилетела и сюда.
А так люди которые не думаю о ошибках памяти, выходах за пределы массивов и прочего, ну они меньше думаю, моск меньше тренируются, результат вот он.
> Уйдут ошибки работы с памятьюНе уйдут.
Как растопрограммы (тонкие клиенты) дергали сишные библиотеки, так и будут. Только теперь с тормозами на библиотечных вызовах, нечитаемым темпорально-паралелльным боровкодом вместо простых последовательных алгоритмов и необходимостью учить ещё один дополнительный язык, угодный корпам с их платными курсами и сертификациями.
Как растобиблиотеки хакались в unsafe {}, пытаясь повторить функциональность сишных библиотек, но беззубо уперевшись в свою безопасТность, так и будут. Только ещё эффект Пельцмана (чувство ложной защищенности) встанет в полный рост.
В "безопасные" сказки верят только те, кто программ никогда не писал или вот только вчера "вкатился" (видимо, с вертушки в щи).
посмотрел исправление async-tar.patch. да, разработчики реализовали неправильную логику обработки заголовка. Но может Rust, всё-таки, виноват в этом? Может Rust настолько сложен, что даже сами разработчики не заметили в этом буреломе кода ошибку? А в простых языках ошибки сразу бросаются в глаза? simpler! ... make it simpler! ... encore un fois!
На самом деле борова достаточно просто запутать. Про это есть баги в багтрекере, но закрывать их не спешат, ибо с текущим боровым вряд ли получиться. Просто ради примеров можно глянуть на ошибки, найденные miri.
Что уж говорить о логических. Не панацея это, не серебрянная пуля. Не надо на нем писать абсолютно все, включая скрипт для веб странички.
Rust настолько божественен, что не считает нужным выпускать спецификации в общество.
(произносить голосом джедая)
- Вам не нужна наша спецификация.
Спецификации иметь надобности нет для вас!
> Rust настолько божественен, что не считает нужным выпускать спецификации в общество.Сейчас придут и скажут, что есть rfc
Кто-то язык выучил, а программировать не выучил )))