В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64093
Это успех, я считаю!Кто со мной согласен - ставим плюсик
Не просто плюсик, а ++ - два плюсика.
С плюсом-плюсом XD
Наконец-то хорошая новость.
И слепой поведёт слепого.
но ведь... но безопасно же и боровы чекают и вообще, нельзя выйти за границу массива и безопасная работа с памятью
Вы не понимаете! Это другое!
А ты зоркий. Молодец, заметил - именно что другое. А то бы налетели сейчас местные сишники-ПравильныеПогромисты... Никаких тебе выходов за пределы буфера, обращения к освобожденной памяти или двойного освобождения памяти... Ну, именно того, от чего и должен спасать раст. А просто "логическая" ошибка. От которой никто не обещал (и не мог) защитить. Не в той позиции что-то там в файле считали и не проверили. Ну это те самые гугловско-майкрософтовские оставшиеся "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% ошибок", которые уже только напряжением мозгов нужно избегатьНу раз напряжением мозгов, то софт на расте точно обречён. Ибо в него и привлекают-то лишь всякими "вам больше не нужно думать о размере буферов и указателях", а основная масса растофанов прекращает читать на слове "думать".
Так это же замечательно, что какой-то инструмент позволяет не думать о том, что к делу не относится и сосредоточиться на прикладной задаче.Необходимость байтодрочерства и прочих ручных управлениях всем, чем можно, пошло от общей убогости компьютерных технологий прошлого (да и нынешнего), а не потому, что это исходно и хотели делать изобретая ЭВМ...
Вот сосредоточиться на прикладной задаче чет не получается.
Тогда пиши на луа и питоне
На другой тип ошибок нужен еще один ЯП!
Может, 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.
Похоже, вы в упор не понимаете разницу между готовыми абстракциями (которые предоставляет 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 не было.Так и сейчас нет.
> Когда даже книжный алгоритм приходится перелопачивать так, что он становится сам на себя не похож.Из этой фразы любому программисту видно, что ты алгоритм заучил, а не понял. Что однозначно определяет тебя как кодера на одном языке, которому никакая клиника уже не поможет.
Мне видно что ты читать не умеешь или какие-то ограничения в мыслительном аппарате, хз. Это где-то в первом классе у детей спрашивают про что пословица "без труда не вытащишь и рыбку из пруда" и они отвечают "про рыбку"
Так а что же ты про техдира гугла не завернул? Вот же он наверное лох, похоже из клиники для реабилитации выступал. Ну или его подло обманули агенты раста с метриками разработки, подло оболгав плюсовиков. Но я конечно поверю тебе, а не ему.> Ты даже не понимаешь о чем речь, сразу видно что вкатился и варился
К твоему сожалению, правда совсем-совсем немного, понимаю. Года три назад, не зная языка, "не вкатываясь", просто взяв примеры кода и подправив их под себя, сделал себе утилитку, работающую с внешними ресурсами (отчеты с биржи стягивает). _Почти_ всё там было понятно и аккуратно. Но да, язык учить надо. Сложное так просто не напишешь. Впрочем, как и на си.
8 лет разрабатываю на Rust, с такими проблемами не сталкивался.
Это проблема только для олимпиадников, которые алгоритмы зазубрили как стишок. Если понимаешь суть алгоритма, нет никаких проблем в том, чтобы его реализовать с ограничениями ownership. (Да, в ряде частных случаев такая реализация станет менее эффективной - тут всегда выбор, или с этим мириться, или воткнуть unsafe. Но это редкость).
> и раздувать изначально компактный код в несколько рази вдогонку, из соседней новости, про принятие в ядро Linux 6.18 реализации Binder IPC для Android, написанная на Rust:
"...Несмотря на продвинутые возможности и поддержку объектов со сложной семантикой владения, драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода."
Ну т.е. после этого нам _очень_ интересно твое "икспертное" мнение. Ты наверное много программ написал сразу в двух вариантах - на си и на расте, чтобы сравнить и выдать свои ценные замечания, верно? Ведь верно?
Сотни других неудобных примеров мы конечно проигнорируем, да?
Эти "сотни других неудобных примеров" только в Вашей голове? Откуда сотни примеров, если Вы и Ваши соратники утверждаете, что на расте вообще ничего не написано?
Ничего не пишут, только переписывают
> Ничего не пишут, только переписываютотлично, о том и разговор.
значит ты легко приведеш примеры где перерисывание с С на Раст раздуло исходники.
> Сотни других неудобных примеров мы конечно проигнорируем, да?Какие сотни, если ты ни одного не привел?
Тебе вон дали буквально из соседней новости: кодя в Linux залит, и по сравнению с сишным стал не только проще, но и компактнее.
Скажешь что-то сожержательное?
Ну даже тут на opennete была куча примеров, что переписали драйвер на расте, функционал меньше, объем кода больше, мне лень гуглить, если у тебя память как у золотой рыбки, какой смысл мне тратить на это время? Все равно ты через секунду забудешь, бросай ты растоманство, совсем с головой худо будет
в одну строку поди писали, все равно ведь раст нечитаемый.
>в одну строку поди писали1. Зачем вы свои проблемы проецируете на других?
2. Чтобы не заниматься догадками, можно полезть в исходный код и посмотреть самостоятельно. Или такое действие слишком сложно для типичного "эксперта“, воина борьбы супротив Rust?
Спойлер. Нет, в одну строчку на Rust (как и на любом другом языке программирования) типичные программисты не пишут.
> Чтобы не заниматься догадками, можно полезть в исходный код и посмотреть самостоятельноА что им смотреть, если они сами пишут, что синтаксис Раста не осилили? Они ж не поймут ничего! 😂
А в байтах какова разница, за вычетом комментариев?
Я
//комментарий раз
могу
//комментарий два
оформить
//комментарий три
предложение
/* очередной бесполезный блок
с комментарием */
так.
Строк многовато вышло, меряться оформлением - так себе затея. А что, индусам за количество строк платили где-то когда-то..Кто-то вообще макросами не часто пользуется, или любит "копировать -> вставить" подобные куски с небольшими отличиями вместо inline с параметрами (навскидку подумалось).
Мне вот больше интересен результат сборки из исходников: быстродействие, применение внешних библиотек, определение/задействование возможностей исполняющей техники (всякие sse, avx, gpu вычисления и прочее-прочее) и всякие UB в исполняемом файле.
Лапша есть и возможна на каждом языке программирования.
Скажите вот эта растовая лапша, почему она вас так цепляет? Давайте проверим.
Макфа? Есть реакция?
Есентуки?
Медведь?
Анон?
Opennet?
Может быть Дядюшка Боб? Что-то есть фиксирую, мы теряем пациента, быстрее введите ему чистый код внутревенно.
Фух вроде отпустило?А если серьезно даже не знаю чел сходи до книжного и прочитай чистая архитектура и идеальная работа.
>Лапша есть и возможна на каждом языке программирования.Не на каждом. Достаточно убрать goto и количество лапши уже резко упадёт.
Как раз таки вырастет и читаемость упадет.
> А сколько багов остаются незамеченными тупо из-за того, что раст вынуждает писать нечитаемую лапшуОткроем-ка осоеднюю новость: https://www.opennet.me/opennews/art.shtml?num=64092
“Использование Rust позволило решить некоторые проблемы с которыми сталкивались разработчики Binder, включая ошибки, связанные с подсчётом ссылок, блокировками и проверкой границ, а также значительно уменьшить сложность обработки ошибок.“
Смотри, эксперт, количество ошибок при использовании Раста только убавилось. Как так?
> раздувать изначально компактный код в несколько раз
Из той же новости:
"драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода."
Смотри, Растовый код не только не раздулся по сравнению с изначальным сишным, но даже стал меньше его! Как так? 😭
> Как так? 😭Боюсь, внятного ответа по теме мы уже не получим. Воин против Раста вон плюсиков за свой вброс получил от собратьев - и все, миссия выполнена.
> Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.Т.е проблема в том что спецификацию расширили не пойми как, включив несколько размеров для одного и того же файла, и интерпретация спеки на Rust выбрала из двух размеров не тот.
Остаётся вопрос почему размер из PAX должен иметь приоритет, ведь теперь проблема может быть обратной - реализации TAR без поддержки PAX будут читать архивы иначе чем исправленная версия.
Legacy? Не, не слышал. Конечно же, виновата спека, а не святые растоманы.
> Legacy? Не, не слышал. Конечно же, виновата спека, а не святые растоманы.Так легаси точно так же этот PAX не читают и точно так же обосрутся как и реализация на Rust)
> спецификацию расширили не пойми какТам всё ещё интереснее. Этих форматов tar было как собак нерезаных. Когда POSIX решил это дело стандартизовать, он взял два формата ustar и PAX и объединил их в один. Это не расширение, это просто какой-то толпоиппизм. Я как-то думал написать реализацию tar в образовательных целях, в рамках ознакомления с каким-то очередным язычком программирования (а заодно и с tar ознакомиться), и забил именно из-за того, что разбираться со всеми этими завихрениями дидовского мышления не было никакого желания.
Но за этим, на самом деле, прячется целая дидовская философия: работает, не трожь. Вместо того, чтобы сделать по уму, они пытаются сделать так, чтобы ничего не делать. Ну, точнее, пытались. Сейчас они наверное все на пенсии уже. Продолжают пытаться ничего не делать.
> Остаётся вопрос почему размер из PAX должен иметь приоритет
На этот вопрос ответить определённо я не могу, увы. Меня не хватило на то, чтобы изучить историю вопроса. Но это намекает на вероятный ответ (тавтологию): если для понимания современного положения дел надо изучать историю вопроса, значит это легаси, где решения определяются не здравым смыслом, а броуновским движением истории, где стандарты не создают реальность, а фиксируют её такой, какая она есть. Отливают её в граните, чтобы и потомкам наших потомков досталось бы.
Ну, это просто доказывает что программисты тупые. Какой язык им не дай, уязвимости из за неправильного подсчета они все равно умудрятся сделать.А шуму то было, мол на расте уязвимостей вообще быть не может, щас как заживем, ух!
> А шуму то было, мол на расте уязвимостей вообще быть не можетЭто от вас, сишников, этот шум. Из раза в раз. От растовиков шум - не будет _только ошибок работы с памятью_ (если не пользоваться ансейфом), а не "всех-всех-всех ошибок". И их, ошибок по памяти, таки пока что-то не наблюдается в товарных количествах, как на божественном.
> От растовиков шум - не будет _только ошибок работы с памятью_ (если не пользоваться ансейфом), а не "всех-всех-всех ошибок"не-не, там еще шум, что раз нет ошибок с памятью, то будет больше времени отловить остальные.
Вот отлов и пошел — tar не так распаковывается, с md5 тоже что-то не так
Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфера
> Вот видите! Вот такими и должны быть баги, логическими ошибками, а не позорным переполнением буфераФфух, мне даже как-то легче стало. Так вот какими они должны быть -- баги на расте! Если я в программе на C сделаю баг как на расте -- можно? Или это будет опять позорный дыряшечный дидовский баг? Или такие баги разрешено делать только на расте, а всем остальным -- ни-ни, не трогай, это на новый год... ой, то есть для раста? Короче, можно полную инструкцию, какими должны быть правильные баги?
Объясняю, почему так вышло - потому что в программе на Си такой баг тоже будет. Но прежде, чем поймать его, вы будете ловить переполнения буффера, двойное освобождение и прочие подобные баги памяти, и только потом логические. А тут вот ловятся сразу уже логические баги. Экономия времени
Во-первых, все баги которые могут случится на чистом Си хорошо документированы и описаны. Кто пишет на чистом Си, и реально желает избежать багов, тот их избежит. Вина в не внимательности и торопливости.>А тут вот ловятся сразу уже логические баги. Экономия времени
Дело не в характере ошибок, делов их в количестве. Не думаю, что общее количество ошибок на Расте меньше, чем в Си.
>Во-первых, все баги которые могут случится на чистом Си хорошо документированы и описаны.Часть багов, которые могут случится на си созданы разработчиками си и называются UB. Ещё часть багов никак не называется, но проистекает из тупой сишной семантики, типа отсуствия гигиенических макросов, нультерминированных строк, отсутствии алгебраических типов и так далее. И что в первом, что втором случае, нужно приложить достаточно усилий, чтобы очередной сишник заметил подвох.
>Дело не в характере ошибок, делов их в количестве. Не думаю, что общее количество ошибок на Расте меньше, чем в Си.Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.
> Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.Это было бы прекрасно, если бы не одно жирное "однако". Однако раст исключает (некоторые) ошибки управления памятью за счет драконовских, вообще говоря, ограничений боровчекера и ценой отказа от множества распространенных (проверенных, отработанных и удобных!) парадигм и техник программирования. Я не говорю уже о тормозах при компиляции из-за туевой хучи проверок и тому подобных неудобствах. Фокус в том, что это все вместе взятое вполне себе увеличивает вероятность появления ошибок остальных 100500 сортов, от которых раст не защищает.
>Однако раст исключает (некоторые) ошибки управления памятью за счет драконовских, вообще говоря, ограничений боровчекераПочему вы до сих пор не предложили не драконовские ограничения? Где соответствующая теория?
>ценой отказа от множества распространенных (проверенных, отработанных и удобных!) парадигм и техник программированияПрограмма должна быть корректной. Если вам так тяжело писать на rust, то почему бы не перейти на языки с gc, типа go или ocaml?
>Я не говорю уже о тормозах при компиляции из-за туевой хучи проверокКоторые вы придумали. Вот пример для крестов https://habr.com/ru/companies/jugru/articles/438260/ когда короткая программа расягивает компиляцию на несколько порядков. Осилите аналогичный пример для rust?
> Почему вы до сих пор не предложили не драконовские ограничения? Где соответствующая теория?О, пардон, я не в курсе что говорю практически с отцом-основателем. Так это вы придумали теорию типов? Снимаю шляпу. Скажите, а часовню -- тоже вы?...
> Программа должна быть корректной. Если вам так тяжело писать на rust, то почему бы не перейти на языки с gc, типа go или ocaml?
А почему бы вам, уважаемый, не перейти туда, куда обычно отправляют тех, кто указывает, кому на каком языке писать?
> Которые вы придумали. Вот пример для крестов
> Наследование реализации не в счёт, в Си его тоже нет.А что это вы, батенька, пример компиляции приводите для C++, а парадигмы решаете ограничить голыми Cями?
Можете привести распространённые парадигмы, от которых отказывается Rust? Наследование реализации не в счёт, в Си его тоже нет.
>Часть багов, которые могут случится на си созданы разработчиками си и называются UB.Неопределённое певедение возникает из-за особенности архитектуры компьютера. Язык Си тут не причём. Все ситуации, при которой может возникнуть неопределённое поведение описано во всех учебниках по языку Си, избежать их не трудно.
>Ещё часть багов никак не называется, но проистекает из тупой сишной семантики,
Из сишной семантики проистекtат только одна ситуация когда в операции сранения программист путает знак < == > со знаком < ==>. Других багов не знаю.
>типа отсуствия гигиенических макросов,
Я даже не знаю, что такое гигиенический макрос, и зачем он нужен.
>нультерминированных строк, отсутствии алгебраических типов и так далее.
Нуль-терминированные строки для относительно низкоуровневого языка нормальное явление. Компилятор не должен заниматься подсчётом строк. Алгебраический тип данных в таком языке как Си просто напросто не нужен. Алгебраический тип данных хорош для языков которые запускаются на виртуальной машине, как Python или Java, или же для мета-языка как C++
>И что в первом, что втором случае, нужно приложить достаточно усилий, чтобы очередной сишник заметил подвох.
Поверь мне чисто-сишнику не нужно прилагать никаких усилий. Надо быть просто внимательным.
Все беды сишников от элементарной невнимательности.>Как только вы отсекаете ошибки управления памятью, то вы автоматически уменьшаете количество ошибок. Логических ошибок от этого больше не становится.
Сравнительного анализа общего количества ошибок в проектах где пишут на Си и Раст, ещё не проводилось. Для чистоты эксперимента должны браться проекты разработка которых началась в примерно в одно и то же время, и имеющих одинаковое количество строк кода. Раст появился недавно, а Си давно и поэтому критики языка Си так изгаляются.
>Если я в программе на 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.
Большинство растеров сами не понимают, что это такое -- афинные типы. Но как звучит! Афинные! Греция, оливки, голые рабы на аренах... Они и бегут, пуская слюни и oбляпaвшись смyзи.
>Большинство растеров сами не понимают, что это такое -- афинные типыТак я не на расте пишу, а вот сишников троллить - одно удовольствие.
>голые рабы на аренахВ Древней Греции рабов на арену не пускали. На арене были атлеты, свободные граждане. Ну да в голом виде, без трусов. Просто нижнего белья как трусы тогда не знали.
> Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...В основном они этим и занимаются, но специфика концепции владения в расте такова, что это не всегда возможно, боровчекер не велит. Ну и код они читать не особо привыкли, "компилируется --- значит, работает", вот их девиз.
Кампания популяризации Rust от корпораций как раз нужна им, чтобы набить кодовую базу для "ИИ", а потом "ИИ" всё будет писать сам. Им для "ИИ" нужен был язык, где нет "утечек" по умолчанию. (хотя это спорно). В итоге в будущем много софта будет AI slop написанным на Rust
> Почему программисты на Rust не могут <буквально> переписать логику с реализацией на C, а придумывают собственные дырявые велосипеды? Вообще, тот факт, что на Rust без ИИ программировать не получается по признанию его фанатов наводит на некоторые размышления...Ну так да, язык рассчитан на то, что человек не может сам нормальный код написать. ВОт только какие-то ошибки он может и отловит, а дальше беда
Не ошибается тот, кто ничего не делает. Давайте зароем топор войны Rust и C!
Вместе с ростом xd
Rust вообще как язык ничего. Растодрочерство бесит, как любая секта.
Ну или проще, хвали свое, но не надо хаять чужое.
Кек.>найден баг в софте на си
растеры: ахаха, фуу, диды, шерето, дырявое, закопать!
>найден баг в софте на расте
растеры: не надо судить так строго, и вообще давайте забудем старую вражду, какое мы вам плохое зло сделали, да и вообще это не баг а фича
Очередные неосиляторы юнит тестов. Попросили бы ИИ написать, даже самим не надо париться.
V in vibrant community means CVE
Сама суть unit тестов в том, что ты их сам пишешь осознанно, и не доверяешь "ИИ" с его галлюцинациями.
Обычная логическая ошибка. Сам Rust не причём.
Ну, в языке C выход за границы массива и "use after free" - это тоже обычные логические ошибки. Сам C не причем.
> Ну, в языке C выход за границы массива и "use after free" - это тоже обычные логические ошибки.Это когда приводят int к uint, получают переполнение с UB?
Что-то логикой тут не пахнет))
> Ну, в языке C выход за границы массива и "use after free"
> - это тоже обычные логические ошибки. Сам C не причем.Нет. Это неопределённое поведение.
Неопределенное поведение - это уже результат таких ошибок.
>>вызвана некорректным выбором позиции в потокеНужно срочно изобрести язык, который защищает от некорректношо выбора позиции в потоке и всё ПО переписать на него.
Может проблема вообще в 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: вот из-за таких как ты, которые говорят "ой, да что там тот раст", раст в ядро так легко и впихнули.
>> Rust же - это залетные -"Ой, в IT платят хорошо". толку от них не будет даже в дальней перспективе, так как rust сдохнет в угоду еще чему нибудь.
> Тут ты уже в фантазии ушел.
> Народ который пишет на расте, зачастую пришли с сишки или плюсов.
> Т.к для других задач естьОткровенный бред нести не надо. Никто с С, а тем более с плюсов на Rust не пойдет (кроме пары процентов совсем отмороженых). Особенно для разработки backend-а, а для frontend-а, ты сам написал - "есть более удобные ЯП со сборщиком мусора." Тот же GO например.
> Откровенный бред нести не надо. Никто с С, а тем более с плюсов на Rust не пойдет (кроме пары процентов совсем отмороженых)."Бред" это ты сам выдумал?
ТОРом пользуешься? Ну так вот создатели ТОР-клиента сами решили создать Arti на замену сишному.
Клоудфларя, амазон, мелкомягкие.. там тоже отмороженные?
Гугл в конце концов: они переводят команды С/C++ на раст.> Особенно для разработки backend-а,
Именно для разработки бекенда.
Если нужны хотя бы какие-то гарантии, а в ультра ограниченную МИСРУ лезть не хочется, а до АДЫ еще не доросли процессы.> а для frontend-а, ты сам написал - "есть более удобные ЯП со сборщиком мусора." Тот же GO например.
Да. Поэтому растом могут заинтересоваться только системщики, которые до его появления довольствовались убогим СИ.
>Откровенный бред нести не надо. Никто с С, а тем более с плюсов на Rust не пойдетПрямо рядом соседняя новость
В ядро Linux 6.18 принята реализация Binder IPC для Android, написанная на Rust - https://www.opennet.me/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.me/opennews/art.shtml?num=64092#118
>>Реализация Binder на Rust аналогична по функциональности с изначальным вариантом на языке Си, проходит все тесты AOSP (Android Open-Source Project) и может использоваться для создания рабочих редакций Android-прошивок. Несмотря на продвинутые возможности и поддержку объектов со сложной семантикой владения, драйвер на Rust получился меньше варианта на Си - 5.5 против 5.8 тысяч строк кода.Я же тебя предупреждал - не делай из себя клоуна.
IPC это InterProcessCommunication. К ядру он имеет весьма опосредованное отношение и работать будет абсолютно по другому. С издержками на передачу данных и т.д.
То-то я думаю что последние Андроед помойку напоминают, из которой мусор уже как 2 редакции не вывозили.
>Сишники которые проблему знают и представляют - таких ошибок не делают.Эти мифические сишники, пишущие код без багов. А вот открываешь список изменений в новой версии, и там всё как всегда. Потому, что недостаточно об этом помнить, нужно проверять каждый указатель и крайне желательно делать это автоматически.
Потому что указатель это не некая магическая сущность, а просто целое число, содержащее адрес байта в памяти (виртуальной а бывает и физической). Осознай это и многое станет понятнее.
Потому что ассемблер так умеет, почему бы и сишке не уметь? А зачем тебе нужна возможность молотком себе по яйцам бить?
>зачем вам нужна возможность разыменновывать nullПотому что в железе нет никакого специального значения null, это как правило адрес 0x0. И это совершенно валидный адрес. На некоторых платформах (DOS, например) его нужно рызыменовывать, там начало таблицы ISR.
Никто не мешает тебе написать ОС, у которой по адресу 0x0 будут находиться какие-то вполне легальные данные.
>>зачем вам нужна возможность разыменновывать null
> Потому что в железе нет никакого специального значения null, это как правило
> адрес 0x0. И это совершенно валидный адрес. На некоторых платформах (DOS,
> например) его нужно рызыменовывать, там начало таблицы ISR.
> Никто не мешает тебе написать ОС, у которой по адресу 0x0 будут
> находиться какие-то вполне легальные данные.Осью это обычно не ограничивается. RESET традиционно начинает с 0го адреса, если принудительно не задано иное. И там будет код jmp или реально исполнимый код. А эту область памяти - код, трогать очень нежелательно. Ну и да, таблицы прерываний - хотя они так-же могут быть перенесены куда-то. Но это не делают. Всем проще считать адрес прерывания 0+
>Осью это обычно не ограничивается. RESET традиционно начинает с 0го адреса, если принудительно не задано иное.Отлично, у нас есть уже какой-то проблеск сознания. А теперь расскажите мне, зачем это нужно в любом более менее прикладном софте? И почему в си это UB, как же тогда прерывания считывать?
ЗЫ я так понимаю, про негигиенические макросы ответа можно уже и не ждать?
Не UB, а implementation defined поскольку архитектуры (сюрприз) бывают разные.
>почему в си это UBА почему в си это UB?
>негигиенические макросы
Это фича, никто ее менять не будет. Видно, что вы не пишете на С, раз задаете такие вопросы.
Если добавлять гигиенические макросы, то они должны быть отдельной сущностью, не те которые #define.
Хотите такие макросы и запрет разыменования null - сделайте прототип нового С. Судя по тому что вы пишете, вам это будет несложно. Если это будет интересно сообществу - вас на руках будут носить.
По крайней мере на x86 RESET НЕ НАЧИНАЕТСЯ с адреса 0, это вас кто-то обманул.
Любопытная новость, спасибо. Хороший пример ошибки, которую может совершить программист независимо от используемого языка.Полагаю, если Rust продолжат форсить по прежнему, мы увидим ещё не один и не два подобных примера.