LINUX.ORG.RU

Уязвимость в Rust-библиотеках для формата TAR, приводящая к распаковке файлов из вложенного архива

 , ,

Уязвимость в Rust-библиотеках для формата TAR, приводящая к распаковке файлов из вложенного архива

0

7

В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка.

Уязвимость также проявляется в форках библиотеки async-tar, таких как tokio-tar, krata-tokio-tar и astral-tokio-tar, а также в утилитах на их основе, например, в пакетном менеджере uv, развиваемом в качестве высокопроизводительной замены «pip» для проектов на языке Python. Из популярных проектов, использующих уязвимые библиотеки, также отмечаются инструментарий testcontainers для запуска docker-контейнеров и WebAssembly runtime wasmCloud. В репозитории crates.is за последние 90 дней библиотека async-tar насчитывает 1.3 млн загрузок, tokio-tar - 2.2 млн, testcontainers - 2.9 млн.

Уязвимость вызвана некорректным выбором позиции при разборе разных значений размера в заголовках ustar и PAX. В tar-архивах в формате PAX для каждого файла внутри архива указываются два заголовка - классический ustar и расширенный PAX. Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.

Для совершения атаки достаточно создать TAR-архив, в котором в ustar-заголовке указан нулевой размер, а в заголовке для формата PAX актуальный размер, из-за чего содержимое файла с другим tar-архивом будет обработано как часть основного архива. Пример кода для создания подобных архивов размещён на GitHub. Уязвимость устранена в выпусках tokio-tar 0.5.6 и uv 0.9.5. Для остальных библиотек исправления пока не опубликованы, но для astral-tokio-tar, async-tar и krata-tokio-tar отдельно подготовлены патчи.

Уязвимости в библиотеках присвоен уровень опасности 8.1 из 10, так как проблема может использоваться для перезаписи распаковываемых файлов (в уязвимых реализациях будут распакованы не те файлы, что были видны в архиве). При этом уязвимость в пакетном менеджере uv отмечена как неопасная, так как если атакующий может влиять на содержимое исходного архива, нет смысла усложнять атаку и эксплуатировать уязвимость через вложенный архив, когда можно добиться выполнения кода через сборочные сценарии в основном архиве.

Выявившие уязвимость исследователи предложили несколько гипотетических сценариев атак, позволяющих обойти проверки безопасности и добиться выполнения кода через замену файлов конфигурации или вмешательство в сборочный процесс. Подразумевается, что присланный архив сможет пройти автоматизированную проверку сканером безопасности и ручной аудит, в ходе которого проверяющий не обратит внимание на странный вложенный архив с другими файлами, после чего при распаковке при помощи Rust-библиотек из архива будет извлечено иное содержимое, чем ожидалось.

Например, атакующий может загрузить модифицированный архив в репозиторий PyPI, который пройдёт проверку на основе анализа содержимого основного архива, содержащего легитимный файл pyproject.toml. При обработке данного пакета при помощи утилиты uv легитимный pyproject.toml будет заменён на вредоносный вариант из вложенного архива, содержащий команды, которые будут выполнены при сборке на компьютере разработчика или в системе непрерывной интеграции. Аналогично, можно организовать перезапись файлов контейнера при извлечении образа контейнера при помощи инструментария testcontainers.

>>> Подробности на OpenNET

★★★★★

Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 2)
Ответ на: комментарий от yvv1

Выберите: вилкой в глаз, или в попу раз? Слабо?

Уязвимость в Rust-библиотеках для формата TAR, приводящая к распаковке файлов из вложенного архива (комментарий)

Да. Это механизм обработки ошибок такой.

Вот и все.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Да. Это механизм обработки ошибок такой.

Вот и все.

Для особо тугих: да, это механизм обработки ошибок.

unwarp - средство отладки программы.

unwarp - средство обработки исключений.

Исключений в расте НЕТ.

Млин, сколько же тугих дятлов среди растохейтеров.

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 2)
Ответ на: комментарий от yvv1

что и как делают другие языки, и зачем они вообще существуют.

Перефразируя одного араба: «Новый язык либо делает так же, как С++ и тогда он не нужен, либо делает по другому, и тогда он делает неправильно».

Думаю, тут можно сделать небольшое обобщение. Указанный эффект будет наблюдаться для адептов любого языка при выполнении двух условий:

  1. Плохое проектирование языка. Программировать на нём должно быть больно, как по детским граблям ходить. Нужно быть весьма одарённым человеком (в хорошем смысле) и потратить годы труда, чтобы научиться не отстреливать себе ногу на каждом шагу.

  2. Распространённость. Язык должен быть настолько распространён вообще или в своей ниши, чтобы преодолев порог обучения, можно было вообще на альтернативы внимания не обращать.

Тогда, понятно, появление нового языка вызывает боль, ибо обесценивает предыдущие страдания и ведёт к страданиям (ибо урок, что изучения языка это долго и больно, усвоен накрепко) новым.

ugoday ★★★★★
()
Ответ на: комментарий от hobbit

если бы писали новое – вопросов бы не было

А с чего ты вдруг решил что кому-то не насрать на твои вопросы?

переписывают то, что уже работает

Удивительное открытие - оказывается программисты не ищут есть-ли уже готовый аналог прежде чем начать писать то, что им хочется. Да быть того не может?! Этак скоро выяснится что художник не ищет в интернете часами голые жопы прежде чем самому нарисовать такое. Или писатель не отказывается от написания своего детектива просто заглянув в соответствующий раздел в книжном. Чем тупее человек тем больше у него сюрпризов в жизни :-D

аргументов по делу

Каких ещё аргументов? С какого перепугу тебе в принципе показалось что разраб должен тебе какие-то аргументы приводить прежде чем начать писать то, что ему хочется на языке, который ему нравится?

Ты как вообще процесс написания программы себе представляешь? Запустил чувак любимый редактор (или нелюбимый если это не Emacs :), размял пальцы, прикинул чего ему интересно наваять… и вдруг резко подорвался «чёрт, я же анонимного дебила забыл спросить о том что мне можно писать - надо срочно бежать на ЛОР!!!»

zabbal ★★★★☆
()
Последнее исправление: zabbal (всего исправлений: 3)
Ответ на: комментарий от ugoday

Тут всё проще. Прогресс идёт, в разработке софта появляются новые методы, которые существенно облегчают жизнь разрабам. Частично эти методы можно реализовать в виде библиотек и расширений языка, но неизбежно наступает момент, когда нужно переделывать компилятор, или рантайм, и ломать обратную совместимость с охулиардом строк старого кода. И вот тут начинается трагедия поколений. Одни становятся грудью на защиту традиционных ценностей, да как так, ломать совместимость, да только через наш труп. Другие кричат: да пошли вы со своей совместимостью, мы хотим, чтобы было всё классно (как в расте) здесь и сейчас. Так и рождаются новые языки. И это хорошо.

yvv1
()
Ответ на: комментарий от yvv1

А исключений в расте нет, поскольку они не очень хорошо сочетаются с концепцией бороу-чекера. Обработка ошибок ведётся стадартными механизмами перечислений и паттерн-матчингом. Всякие unwrap_* и ко - это всего лишь обёртка над match блоками. Это работает хорошо, так что никакие особые механизмы для обработки ошибок типа исключений в расте не нужны. Вообще в этом вашем расте всё довольно неплохо продумано, если вдуматься.

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от yvv1

Обработка ошибок ведётся стадартными механизмами перечислений и паттерн-матчингом. Всякие unwrap_* и ко - это всего лишь обёртка над match блоками. Это работает хорошо, так что никакие особые механизмы для обработки ошибок типа исключений в расте не нужны.

Какие вы смешные, растофанатики, свидетели иеговы курят в сторонке.

А давай смоделируем ситуацию - например есть какая-то либа, она принимает на вход коллбэки от тебя и делает какие-то действия. Эта либа клала большой и жирный болт на твои там внутрисофтовые энумы и паттерн матчинги, она тебе возвращает лишь какой-нибудь int в итоге. В процессе выполнения кода либы, внутри коллбэка ты понимаешь, что что-то пошло не так и нужно остановить алгоритм немедленно и вернуться с ошибкой. Коллбэк не может просигналить внутрь алгоритма остановиться. Давай пофантазируем ещё - ты не знаешь каким потоком будет выполняться алгоритм, он будет вызываться многопоточно из Thread Pool’a. Как?

kvpfs_2
()
Ответ на: комментарий от kvpfs_2

Ну, тут всё просто: вызываем исключение, и колбек валит вызывающий его код и ещё пучок алгоритмов в том же треде, шикарно же!

unC0Rr ★★★★★
()
Ответ на: комментарий от kvpfs_2

Эта либа клала большой и жирный болт

Тогда эта либа отправляется на помойку. Если ты пишешь либу на расте, либо ты пишешь её «идиоматик вей», либо она идёт на помойку.

Нет, я не против исключений, всегда ими пользуюсь в тех языках, где они есть. Но в расте их нет, и на то есть причина. Зато есть другой, не менее гибкий подход к обработке ошибок. Это компромисс в дизайне, который выбрали разрабы. В любом язычке таких компромиссов - вагон и маленькая тележка.

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от yvv1

У меня этот сайт не открывается.

Не нужно мне весь мануал пересказывать, что разве нельзя в одно предложение ответить что будет ? Это что сложно так?

Вот мне гугл набросал, хз правильно ли. Что будет если это выполнить при условии что файла example.txt нет:

use std::fs::File;

fn main() {
    let mut file = match File::open("example.txt") {
        Ok(file) => file,
    };

}

это я пытаюсь объяснить, что прежде чем заявлять:

Исключений в расте НЕТ.

Нужно попытся понять что такое исключения.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 3)
Ответ на: комментарий от mx__

У них там возвращается Result, который говорит всё ли ок. Но тут прикол в том, что у стд свой энум для ошибок, у любой другой либы сторонней - аналогично свой, и всё это нужно сопоставить во внутресофтовый энум. В итоге простой плюсовый код:

ifstream f2() {
    ifsteam file("nonexisted.txt");
    return file;
} 

превращается в такую парашу многословную:

fn f2() -> Result<File, MyError> {
    match File::open("nonexistent.txt") {
        Ok(f) => Ok(f),
        Err(e) if e.kind() == io::ErrorKind::NotFound => Err(MyError::FileNotFound),
        Err(e) => Err(MyError::Io(e)),
    }
}

Ну не знаю, такое себе, очень на любителя

kvpfs_2
()
Последнее исправление: kvpfs_2 (всего исправлений: 1)
Ответ на: комментарий от kvpfs_2

Вообще то это и называется ОБРАБОТКОЙ исключений - которой по утверждениям некоторых в RUST - НЕТ !

mx__ ★★★★★
()
Ответ на: комментарий от mx__

Этот пример во-первых неправильный, что очень странно, т.к. чатботы умеют генерировать такие примеры в целом правильно.

Во-вторых, std::fs::File::open(path) возвращает Result, который в случае ошибки равен std::io::Error. А дальше ты решаешь, что с ним делать. Пример из документации:

fn read_file() -> Result<String, Box<dyn Error>> {
    let message: String = fs::read_to_string("message.txt")?;
    Ok(message)
}

В данном случае значение Error просто передаётся наверх в вызывающую функцию. Вот эта вся мишура Box<dyn Error> нужна потому что конкретный тип ошибки заранее неизвестен, аллоцируется динамически.

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от mx__

Вообще то это и называется ОБРАБОТКОЙ исключений - которой по утверждениям некоторых в RUST - НЕТ !

Лично ты можешь называть это как угодно, но исключений в том виде, в каком они есть в плюсах или в питоне, в расте действительно нет.

yvv1
()
Ответ на: комментарий от yvv1

Не, ну супер)). Т.е. для тривиальнейшей задачи, чтобы как-то комфортно возвращать ошибки без всей этой возни с разными типами, вы: 1. выделяете память в heap’е. 2. косвенные обращения (сколько там вони всегда поднимается про полиморфизм).

А чем исключения так плохи (ну мне чисто для ликбеза)? unC0Rr и другие растаманы не видят тип летящих исключений?

kvpfs_2
()
Ответ на: комментарий от kvpfs_2

вы: 1. выделяете память в heap’е.

А вы что, не выделяете?

  1. косвенные обращения (сколько там вони всегда поднимается про полиморфизм).

Какие у вас проблемы с полиморфизмом?

А чем исключения так плохи (ну мне чисто для ликбеза)?

Да ничем. Я же писал, я ими всегда пользуюсь, но не в расте. В расте всё по-другому из-за бороу-чекера (я об этом тоже писал).

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 3)
Ответ на: удаленный комментарий

Кто знает, может это критически важно, может от этого зависит обороты чего-нибудь и в перспективе разрушение

Ну да, ну да. Программа спрашивает у функции «какое значение оборотов выставить?», а функция решает, что неплохо бы прибить тред. Программа, естественно, понятия не имеет, что делать в случае исключения в этой функции (в контракте они не прописаны), и всё красиво падает. Ура, мы из колбека уронили основной алгоритм, который должен был предотвратить разнос железяки!

Изумительно, как вы преподносите самые сильные минусы исключений как их преимущество.

unC0Rr ★★★★★
()
Ответ на: комментарий от kvpfs_2

Пишется один раз инстанс Into из либового энума в собственный, и дальше вся эта портянка заменяется на один знак вопроса в каждом месте применения.

unC0Rr ★★★★★
()
Ответ на: комментарий от yvv1

Лично ты можешь называть это как угодно, но исключений в том виде, в каком они есть в плюсах или в питоне, в расте действительно нет.

Ты тоже можешь продолжать дальше упираться и называть исключения в расте не исключениями. Надеюсь до тебя дойдет это хотя бы лет через 30.

mx__ ★★★★★
()
Ответ на: комментарий от mx__

std::expected в цпп23 - это исключения или нет? Это прямой аналог растовского Result.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Знаешь, я вот честно сегодня попытался вникнуть глубже в растовый аналог си++ исключениям. По итогу - вижу какую-то кучу лишних телодвижений, многословность, везде Result этот, unwrap() этот всюду т.к. растаманы не хотят париться и передавать на вверх (что в случае исключений из коробки). А чем это сильно лучше исключений я так ответа и не нашёл. Если там чуть менее жирный рантайм только (не думаю, что сильно). Но исключения чище и элегантней.

Я тебе это честно, такие впечатления остались

kvpfs_2
()
Ответ на: комментарий от mx__

Ты тоже можешь продолжать дальше упираться и называть исключения в расте не исключениями.

Не согласен. Исключение (в языках, в которых они есть) прерывает поток программы и автоматически перехватывается выше по стэку. Ни то, ни другое не обязательно происходит в расте. Result<T,E> не прерывает поток, а только возвращает результат со значением E в случае ошибки. Что с этим результатом делать, решает вызывающая функция. unwrap вызывает panic!, который прерывает поток, но выше ничего само не перехватывается, программа либо сразу абортится, либо разворачивает стэк в зависимости от опций компилятора. Т.е. нет, это всё не исключения в классическом смысле. Некоторые считают такой подход более продвинутым по сравнению с исключениями, но я хз, в данном случае просто пользуюсь тем что есть.

yvv1
()
Ответ на: комментарий от kvpfs_2

А чем это сильно лучше исключений я так ответа и не нашёл.

Я тебе уже джва раза ответил, это плата за бороу-чекер. Разрабы видимо посчитали, что плата оправданная. А кто-то считает это не платой, а бонусом, но это субъективно.

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 1)
Ответ на: комментарий от kvpfs_2

Окей, я понимаю такую точку зрения, но не согласен. Весь мой опыт говорит, что подход раста лучше. Явный контракт лучше неявного. Всё, что можно нарушить, не получив по рукам от компилятора, будет неизбежно в какой-то момент нарушено. И рассматривание логов будет слабым утешением, когда рядом будет стоять бригада ремонтников, заменяющих агрегат.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Я детали не знаю, где читал точно не помню. Но проблема вроде с неявным управлением потоком (implicit control flow) в случае с иключениями. Как-то там сложно удовлетворить правилам бороу-чекера в этих условиях. Но я программист не настолько упоротый, чтоб разбираться в таких внутренностях языка, поэтому в данном вопросе верю всему интернету на слово. Слышал звон короче.

yvv1
()
Последнее исправление: yvv1 (всего исправлений: 3)

Ооо, ну все понятно. Все понятно, ну, ооо…

А вот переименовали бы master в main раньше, не было бы такого свинства.

water_closed
()
Ответ на: комментарий от hobbit

Вот тоже верный маркер, хамить начинают обычно, чтобы скрыть отсутствие аргументов по делу.

100%

Это очень распространённый и очень же примитивный приём, хорошо известный психологам: обесценить, «расчеловечить», заранее принизить значимость оппонента в духе «Да кого вы слушаете?? Он же...» ( вместо многоточия следует обычно «ушат помоев», выливаемый на оппонента или предмет обсуждения, призванный обозначить, почему «не стоит даже и слушать» оппонента либо обсуждать этот предмет спора, а сразу надо перейти на точку зрения «поливающего» :) ), чтобы прикрыть и компенсировать собственную несостоятельность в споре.

Я сейчас набираю ответ одному такому (чуть ниже этого вашего сообщения его сообщение-«ответ» мне, в таком же стиле «развенчивающий» как С — в «пользу» Rust, разумеется :), — так и тех, кто на нём пишет...). Когда (и если: мне трудно печатать одной рукой) наберу, укажу «товарищу» и на этот его «грязненький приёмчик»... :)

Somebody ★★★★
()
Ответ на: комментарий от dataman

Нет.

Вторая рука — следствие проблем со здоровьем, к программированию отношения не имеющее никакого.

Но сейчас это сильно мешает работать, да...

Somebody ★★★★
()
Последнее исправление: Somebody (всего исправлений: 1)
Ответ на: комментарий от zabbal

Вообще-то и язык и даже ide выбирает заказчик. Люди знаешь кушать хотят, потому работают на дядю. А вот дядя вкладывает миллионы баксов в раст и напрямую и через разные фонды и очень хотел бы показать инвесторам, что делается это не зря, а во имя так называемой безопасности они отвлекают человеческие и финансовые ресурсы, от решения куда более насущных проблем.

Потому и переписывают уже имеющееся - так в сотни раз проще, чем писать что-то с нуля.

Ygor ★★★★★
() автор топика
Ответ на: комментарий от Ygor

очень хотел бы показать инвесторам
во имя так называемой безопасности

Вот именно!.. Одна показуха, навязчивая, грубая пропаганда и истерические вопли сторонников «ржи»...

Somebody ★★★★
()
Последнее исправление: Somebody (всего исправлений: 1)
Ответ на: комментарий от Ygor

А вот дядя вкладывает миллионы баксов в раст

О чём ты говоришь, дружище. В моей реальности, дядя с деньгами пока что вкладывает в си на порядки больше баксов, чем в раст. Да, есть такой недостаток у раста, что найти дядю, который бы тебе за него заплатил, не так уж просто. Но это временно.

yvv1
()
Ответ на: комментарий от unC0Rr

в своем расте вы что-то не сильно таскаете критические ошибки через стек вызовов, просто зовете unwrap() и абортитесь

Для приложений это может быть вполне нормальным подходом. В библиотеках никто в своём уме unwrap не пишет.

Кстати, а вот вообще не факт. Я для интереса грепнул по первому попавшемуся раст проекту на гитхабе, так там unwrap’ов на 3 страницы поиска, и это не только в тестах или примерах, это прям в самих исходниках проекта. И нет, там чистый unwrap, а не unwrap_or… . А где-то там прям напрямую вызвали panic.

Сделал для себя ещё одно открытие - ведь в расте есть и классические исключения в чистом виде с размоткой стека. Ну а чем является std::panic::catch_unwind, если не им самым? Такие же сайд эффекты и передача управления в случае чего. Т.е. на менее жирный рантайм рассчитывать смысла нет, там есть всё тоже самое, что и плюсовом.

Чет как-то хреново работает вся это концепция, коллега растаман спокойно может уронить тебя в библиотеке. Впитав вот этот весь раст вей, наивный растамн спокойно уронит софтину управляющую «ядерным реактором». Для плюсовика исключения хотя бы ожидаемы, на самом верху обработчики будут завернуты в try, и софтина пусть и хромая (без возможности отправить что-то по сети, например, ибо васянская либа эксептится), будет и дальше работать способная выполнять свою работу, то для растомана это все как гром среди ясного неба

kvpfs_2
()
Ответ на: комментарий от Ygor

Вообще-то и язык и даже ide выбирает заказчик.

Это в маня-мирке мамкиных бизьнесьменов, мнящих себя повелителями вселенной. В реальности заказчик до таких мелочей не опускается.

миллионы баксов

ide выбирает

Может ещё и с ложечки пюрешечкой кормит за такие бабки?

IDE программист использует какую хочет - лишь бы под формальные требования конторы подходила (не ломаная паль, без дыр ИБ), да и то если не в BYOD работа. Язык выбирает тимлид из того что доступно в техрадаре, который наполняют техлиды, бурча про легаси и говно.

А уж в случае FOSS всем вообще глубочайше насрать на каких-то там заказчиков по причине периодического отсутствия таковых.

zabbal ★★★★☆
()
Ответ на: комментарий от kvpfs_2

там unwrap’ов на 3 страницы поиска

Я глянул, большинство - это что-то вроде tx.try_send(req).unwrap(), т.е. прямо следует документации, многие находятся в тестах (например, все 14 в proto/h1/decode.rs), некоторые над статическими данными, когда нет смысла обрабатывать ошибку, её никогда не будет (например, Uri::from_str("/").unwrap()).

Паники по делу, судя по комментариям перед ними.

std::panic::catch_unwind

Есть, но пользоваться им не надо.

жирный рантайм

Вызов panic! не обязательно ведёт к раскрутке стека, может просто делать аборт, и ничего ты не поймаешь.

софтина пусть и хромая … будет и дальше работать способная выполнять свою работу

Это так не работает. Если возможность какого-то исключения не предусмотрена в программе, то нет и адекватной обработки оного. Может, программа может продолжать работать, а может, это исключение вызывается, потому что нарушился какой-то инвариант в данных из-за бага, и продолжать ни в коем случае нельзя.

unC0Rr ★★★★★
()
Последнее исправление: unC0Rr (всего исправлений: 1)
Ответ на: комментарий от unC0Rr

Я глянул, большинство - это что-то вроде tx.try_send(req).unwrap(), т.е. прямо следует документации, многие находятся в тестах (например, все 14 в proto/h1/decode.rs), некоторые над статическими данными, когда нет смысла обрабатывать ошибку, её никогда не будет (например, Uri::from_str(«/»).unwrap()). Паники по делу, судя по комментариям перед ними.

Нет-нет-нет, это все беда и ужас. 1. tx.try_send(req).unwrap() - это фу, оно может абортнуться. 2. Вот такие вот unwrap’ы создают ощущение у юных растоадептов, что это норм, ну а чего, все так делают. Этого не должно быть вообще в приличных местах, тем более в библиотеках. 3. Мне вот очень нравится в плюсах, что в комитете они там догадались, что не должно быть чистых new в коде, и вкрутили всякие make_unique(). Я могу просто грепнуть проект и сделать выводы о проекте и стоит ли его использовать в своем коде. Если там new на new (не placement), то этот проект я обойду мимо. Будь я растаманом с желанием подцепить в свой проект какую-то либу, я бы обязательно грепнул этот проект на наличие там unwrap(), если оно там есть, то мимо. Но дело в том, что я подготовлен минимально хотя бы, неокрепший же ум наивного наивного растамана может сильно пострадать, он столько слышал про безопасность, такой свиньи он вообще не ожидает.

Вызов panic! не обязательно ведёт к раскрутке стека, может просто делать аборт, и ничего ты не поймаешь.

Но таки есть, значит в рантайме раста есть полноценный механизм обработки исключений. Плюсовому компилятору тоже можно дать флаг, и любой выброс исключений будет абортиться. Кстати, можно даже свою обработку исключений закостылить, я как-то игрался, просто пишешь обработчики с нужными именами и делаешь в них что хочешь, никакой особой магии в исключениях нет, только некоторая служебная инфа в бинарях присутствует.

Это так не работает. Если возможность какого-то исключения не предусмотрена в программе, то нет и адекватной обработки оного. Может, программа может продолжать работать, а может, это исключение вызывается, потому что нарушился какой-то инвариант в данных из-за бага, и продолжать ни в коем случае нельзя.

Это именно так и работает. Исключения нужно уметь. STL контейнеры дают strong exception safety guarantee, что уже не мало, подготовь временный контекст, выполни задачу, если ок, то модифицируй настоящий контекст временным. Если какая-то васянка настойчиво шлет исключение, то перезапускай эту задачу там раз в минуту. Самое главное - правильный дизайн, ну некоторая минимальная сложность, когда все это становится нужными и лучше чем просто аборт().

kvpfs_2
()
Последнее исправление: kvpfs_2 (всего исправлений: 1)
Ответ на: комментарий от kvpfs_2

А ещё нюанс в том, что начал я проект на расте, думаю: «не буду париться с передачей ошибок, пусть падает, хеллоу ворлд ведь». Проект усложняется, и друг мне начинает хотеться не падать, а передавать ошибки на самый верх для принятие дальнейших решений. Мне придется перелопатить и модифицировать кучу кода, это всегда очень больно трогать уже отлаженное.

С исключениями такой проблемы нет - я пишу хеллоу ворлд, все абортится, меня устраивает. Захотел передавать исключения на верх - пишешь обработчик, несколько строк, минимум телодвижений.

kvpfs_2
()
Ответ на: комментарий от kvpfs_2

Проект усложняется, и друг мне начинает хотеться

А что угодно начинает хотеться, и лучше, если компилятор подскажет, когда твои хотелки несовместимы с текущим кодом, чем ты срежешь все углы и будешь отлаживать по логам, надеясь ничего не упустить.

unC0Rr ★★★★★
()
Ответ на: комментарий от kvpfs_2

То швыряемся в плюсах исключениями как хотим и пусть прогер на верхнем уровне ловит и в лог суёт, а пользователь плачет в саппорт, то в расте паника уронит ядерный реактор. Двойные стандарты они такие двойные…

andalevor ★★★
()
Ответ на: комментарий от yvv1

и расширений языка, но неизбежно наступает момент, когда нужно переделывать компилятор, или рантайм, и ломать обратную совместимость с охулиардом строк старого кода.

Вот тут неявно подразумевается, что есть какой-то один язык. Если кто начал с С, перешёл на С++ и там застрял, то да, так и выходит. А если после С возникли python и ocaml, то скорее всего мозги выйдут гибче и появление ещё одного языка со своей моделью исполнения, плюсами и минусами не будет вызывать мучительно жжение в месте, где спина утрачивает своё благородное название.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

тут скорее умение абстрагироваться

таже эмуляция машиной Тьюринга остальных машин Тьюринга предполагает вот это абстрагирование

ваще если не касаца(sic) всякой фунциклятины то реальное обучение языку это прокурка что есть память - ака массив по индексам(адресам) читаем пишем - и для убобства что размер ячеек совпадает с адресным пространством - ну и плюсом сам код тут же в сих ячейках

ваще структуры (хранения) данных >)

ну и да хацкель мозги ставит на место - тока текущая коньюктура индустрии в другом месте и мы даже знаем в каком

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

реальное обучение языку это прокурка что есть память - ака массив по индексам(адресам) читаем пишем

В тред заходит гипотетический java-сеньор и начинает гонять байтодрочеров по паттернам проектирования. Потому как рядом есть паралельный мир и там тоже можно окостенеть мозгами, но совсем-совсем по-своему.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

патерн стек в языке без рекурсии

все эти патерны признаки не адекватности языков

qulinxao3 ★☆
()
Ответ на: комментарий от ugoday

фишка с адресами в том что это имена (просто в нумерах - хехе Гендель(ф) не даром все высказыванию занумеровал для кутежа)

т.е. пояснение за массив памяти это про магию имён

ваще Go to considered harmful(by name isfrom Wirth by value isfrom De IJK str'a) о важности стабильности координат - для кода это отказ от блужающих ip/pc для данных это попытка заобстрагироваться от произвольного чтения_письма в память(даже данных а уж если код на ходу тюнить то такой полиморф им не нужон) посредством наворачиванию дисциплин структур{Хранения - прям рекурентность cлоёв когда субд крута но пользователи не в курсах ея Унутрянки[У] и публичных интерфейсов к ним и следовательно лепят теже[из У](в лучшем случае) структуры данных поверх всеобщего интерфейса SQL20XX} данных и ойных ADT/АТД c чОткими интерфейсами - а как там под капотом не сеньёрского умка дела

вот и получается микросёсисы

а вы гойворите патёрны

qulinxao3 ★☆
()
Последнее исправление: qulinxao3 (всего исправлений: 3)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.
Тема будет перемещена в архив .