Атака на пакет arrayref Rust

Даже простейший hello world невозможен без unsafe.

Не, ну уж не надо так сильно преувеличивать.

А я и не преувеличиваю, println вызывает io::write, который пишет в stdout, внутри которого unsafe

Ну ок. Дался Вам этот ансейв.

Просто существуют, разрабатываются и исследуются другие подходы к безопасности памяти, отличные от раста, например тот же вале и другие. Может быть и не надо спешить внедрять модель раста в с++, если она далека от идеала. В общем, надеюсь, есть люди поумнее, которые на этом собаку съели, и именно они будут предлагать стандарт safe c++ :)

Просто существуют, разрабатываются и исследуются другие подходы к безопасности памяти…

Почему не используются в мейнстриме тогда?

Может быть и не надо спешить внедрять модель раста в с++

Кто-то этим вообще занимается? Кажется никому этого не нужно, уже есть раст, все потихоньку забивают на сишку.

В общем, надеюсь, есть люди поумнее, которые на этом собаку съели, и именно они будут предлагать стандарт safe c++ :)

Нужно только подождать, ага!

Unsafe не проблема, это метод локализации опасного кода, это неотъемлемая часть языка, область которого, вероятно, будет сужаться с развитием компилятора. А писать в stdout безопасно по определению не получится.

Список же потому и выбирают

Не обязательно, а с такой реализацией вообще не выбирают. Это пример возможностей системы типов, одна из… Можем и дальше поупарываться. Например, можно прицепить итератор к списку за счёт утяжеления:

struct DIter<T> {
    node: NodePtr<T>,
    prev: NodePtr<T>,
    next: NodePtr<T>
}

prev, next, берутся из ноды, а в самой ноде, один из них будет сигнализировать (если null) что на ноде висит итератор(-ы), а второй на на этот итератор указывать. Так сильно сэкономим на и так дорогих интрузивных указателях - размер нод останется такой же, а итераторов должно быть, по идее, сильно меньше чем нод. И при отработке общего деструктора во всех итераторах занулится поле node. Теперь безопасный интерфейс итератора может выглядеть так:

impl<T> DIter<T> {
    pub fn go_next(&mut self) -> Option<()> {
        // чехарда с указателями
    }
    pub fn go_prev(&mut self) -> Option<()> {
        // чехарда с указателями
    }
    pub fn modify_val(&self, fun: impl FnOnce(&mut T))  -> Option<()> {
        if self.node.is_null() { return None }
        unsafe { fun( &mut (*self.node).val ) }
        Some(())
    }
    pub fn remove_node(self) {
        // чехарда с указателями
    }
}

Лайфтайм теперь не привязан к списку, можем и итерироваться и менять ноды независимо. modify_val(&self, fun: impl FnOnce(&mut T)) - это позволяет сейфово и эффективно(растовые ссылки самый быстрый вид косвенности) работать с val и гарантировать(совместно с однопоточностью) уникальность &mut ссылки. FnOnce позволяет принять и функцию и замыкание любого типа, с одинаковой и максимально эффективной оптимизацией. В плюсах же с обычными ф-ми - как повезёт.

remove_node(self) - а вот это (мув самого себя в никуда) - в плюсах нельзя повторить. Методы go_next, go_prev могут вызвать произвольный убшный бабах после удаления ноды. Раст статически и зерокостно не даст после вызова remove_node(self) вызывать какие-либо методы на этом итераторе. В плюсах можно «защититься» от этого только дополнительной рантаймовой проверкой в этих методах.

Кто-то этим вообще занимается? Кажется никому этого не нужно, уже есть раст, все потихоньку забивают на сишку.

Комитет же

Нужно только подождать, ага!

да, как ни странно, просто подождать

Я не совсем понимаю, что ты хочешь получить сейчас. Если список, подобный с++, но на safe rust, то у тебя же внутри уже есть unsafe. Ссылка на вариант, написанный полностью без unsafe была выше. Там немного замысловатый интерфейс и список разделяет владение элементами, но вариант вполне рабочий.

А в твоём варианте, что будет если два итератора указывают на один и тот же элемент и оба одновременно вызовут modify_val?

А что ты имел ввиду под «подсчёт ссылок» если не Rc?

… в СВЯЗНОМ СПИСКЕ.

Подсказка: Нода либо принадлежит списку, либо освобождена.

Ссылка на вариант, написанный полностью без unsafe была выше.

Нет, в RC есть, как минимум память без ансейфа не выделить, но и без этого его там полно. Вообще это не важно и хейтерская шиза, в смысле, факт наличия unsafe кода или высчитывание процентов ансейф кода. Это не какая-то сифа, а нормальная и полноценная часть системы обеспечения корректности кода. Наличие unsafe с соответствуещей системой типов означает что в языке есть safe, т.е. можно сделать типы/интерфейсы с сейфовостью не отличимой от встроенной, что бы это не значило. Формально: ансейф код + доказатеьство и обеспечение сейфовости строго равно сейф, плюсы так вот не умеют, и мало кто вообще умеет. И ещё, это ортогонально производительности, в обе стороны влияет.

что будет если два итератора указывают на один и тот же элемент и оба одновременно вызовут modify_val?

Нормально будет. Времена жизни передаваемых аргументом ссылок ограничены вызываемой fun и, следовательно, в однопоточном коде не пересекутся, и с деструктором списка тоже. Из-за которого и нельзя просто выдать(как в первой версии) куда-то ссылку на неопределённый срок, может отработать деструктор при всё ещё живой ссылке и она повиснет, а в расте это прям жёсткое УБ

Нет, в RC есть, как минимум память без ансейфа не выделит

Ну да, без этого никак, мы уже выяснили, но в коде самой библиотеки со спикском unsafe нет. То есть ответственность на разработчиках стандартной библиотеки раста. Подразумевается, что там всё очень надёжно. И мне не надо доверять unsafe коду, который написал ты. И твой код с опасным unsafe это ярко иллюстрирует.

что будет если два итератора указывают на один и тот же элемент и оба одновременно вызовут modify_val?

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

А если один modify_val вызвать из другого?

a.modify_val(|x| {
    *x += 1;

    b.modify_val(|y| {
        *y += 1;
        *x += 1;
    });
});

Если a и b указывают на один элемент, то первая fun ещё не закончилась, когда вызывается вторая. Получается, в этот момент одновременно живы две mutable-ссылки на один T?

И мне не надо доверять unsafe коду, который написал ты. И твой код с опасным unsafe это ярко иллюстрирует.

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

А если один modify_val вызвать из другого?

Ну да, я по лени не стал расписывать в подробностях всё что было в голове, просто демонстрировал возможности. Такой вот дизайн итератора:

struct DIter<T> {
    node: NodePtr<T>,
    prev: NodePtr<T>,
    next: NodePtr<T>
}

подразумевает что на ноде может сидеть только один итератор, и методы go_next, go_prev должны обеспечить это или с остановкой выдавая «занято» или, в другом варианте, перескочив через занятую ноду на следующую (вполне обычная логика для списков - найти «свободную» ноду). И в определении «fn modify_val(&self,», естественно, должно быть «&mut self» (тут я зевнул), и вызвать modify_val внутри другого modify_val на одном и том же итераторе не получится. И ещё у итератора должен быть деструктор который вернёт указатели prev, next обратно в ноду, на случай если remove_node() не вызывался, а скоуп в котором сидел итератор кончился.

И мне не надо доверять unsafe коду, который написал ты

Тут важно что unsafe-ый контракт не получиться забыть или, что даже важнее, не поставить по капризу вида - «да у меня стаж в сишке ого-го и я ошибок не делаю это всё какие-то другие неправильные сишники говнокодят» - что выводит вопрос в чисто формализованную технологическую плоскость.

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

Хотелка была - список на safe rust, если что. Ну да ладно, допустим ты хочешь сделать как на с++, просто с safe API, пусть с unsafe внутри. Но тогда вот это твоё ограничение «на ноде может сидеть только один итератор» всё ломает. В std::list может хоть сто итераторов указывать на одну ноду. Если уж ты хочешь добиться чего-то похожего на std::list, то надо это разрешить, как это позволяет, например, rc-dlist-deque. В нём сколько угодно итераторов могут ссылаться на одну ноду без проблем. И только для получения эксклюзивного mut& вступают в игру ограничения.

И мне не надо доверять unsafe коду, который написал ты

Тут важно что unsafe-ый контракт не получиться забыть или, что даже важнее, не поставить по капризу вида - «да у меня стаж в сишке ого-го и я ошибок не делаю это всё какие-то другие неправильные сишники говнокодят» - что выводит вопрос в чисто формализованную технологическую плоскость.

Так ты же буквально только что продемонстрировал обратное :) В первой версии modify_val(&self, …) ты как раз забыл часть unsafe-контракта, и у тебя через полностью safe API можно было получить UB. То есть unsafe хорошо локализован и заметен, но корректность его контракта компилятор за тебя уже не проверяет. Поэтому, собственно, я и прошу пример без unsafe. Ну да ладно, это уже лирика.

«premature optimization is the root of all evil»

☝️ «the root of all evil is the heart of a black soul» (c) (youtube.com)

А тут как раз доклад по поводу этой фразы вышел.

@dimgel

https://www.computerenhance.com/p/theroot

Одно время я слушал стримы Евгения Спицына (историк наш), пока однажды, когда он в очередной раз сыпал по памяти десятками имён каких-то хренов третьего ранга принятия решений из начала прошлого века, не ужаснулся до корней волос: он сделал своей профессией копание в чужих жизнях вместо проживания собственной.

А сама фраза – бред собачий. Точно так же можно сказать про «premature architecture»: даёшь agile во все дыры! Лично я никогда не занимался оптимизацией целенаправленно, я просто чистил нагромождения говнокода и говно-архитектуры; ускорение на 2-3 порядка получалось при этом само собой. (Хотя вру: многие вещи у меня настолько давно уже в рефлексах, типа например prepared statements, что я их даже не замечаю.) А если заранее не видишь в общем и целом, что хочешь получить на выходе, то вляпаешься в проблемы в любом случае.

он сделал своей профессией копание в чужих жизнях вместо проживания собственной

Почему обязательно вместо, а не вместе? А условных программист, который делает своей профессией копание в куче UB и особенностей реализаций, или кучу плохо совместимых между собой ассемблеров, или куче стандартов C++, тоже делает это вместо проживания своей жизни? А условный физик, делающий своей профессией копание в квантах и кварках, да спинах с зарядами?

Профессия и знания, в неё входящие не заменяет жизнь, а является её составной частью. У нормальных людей не единственной.

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

Обсуждаемая фраза – «the root of all evil» – максимально категорична и не предполагает использования мозгов.

Куча UB и стандартов, а точнее, куча мелких нюансов, увеличивающаяся с каждым новым стандартом – это на самом деле про то, что C++ откровенно говёный язык. Только маньяки буду просирать свою жизнь, выискивая разные виды глистов в этом продукте чужой жизнедеятельности, или (как я) воюя с ним из нежелания отказываться от высокоуровневости и низкоуровневости в одном флаконе. А кто поумнее – возьмут что-нибудь попроще и субъективно поудобнее, и будут больше времени проводить с детьми.

Обсуждаемая фраза – «the root of all evil» – максимально категорична

Да.

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

Предполагает. Адекватный человек должен понять, что не стоит воспринимать эту фразу как догмат, а отнестись к ней следует с некоторым скепсисом. Это и есть использование мозгов.

Куча UB и стандартов, а точнее, куча мелких нюансов, увеличивающаяся с каждым новым стандартом – это на самом деле про то, что C++ откровенно говёный язык.

Не спорю.

Только маньяки буду просирать свою жизнь, выискивая разные виды глистов в этом продукте чужой жизнедеятельности, или (как я) воюя с ним из нежелания отказываться от высокоуровневости и низкоуровневости в одном флаконе

Нет, не только маньяки. Есть множество других расстройств, ведущих, к похожим результатам, но не являющихся манией ;)

А кто поумнее – возьмут что-нибудь попроще и субъективно поудобнее, и будут больше времени проводить с детьми.

Возможно. Хотя и часть из тех, кто поглупее, тоже ;)

Обсуждаемая фраза – «the root of all evil» – максимально категорична

Да.

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

Предполагает. Адекватный человек должен понять, что не стоит воспринимать эту фразу как догмат, а отнестись к ней следует с некоторым скепсисом. Это и есть использование мозгов.

В логику умеют не только лишь все.

Обсуждаемая фраза имеет контекст, как в виде статьи, в которой написана, так и в виде своей компьютерной эпохи.

Неверно - ни синтаксически (не вижу в тексте самой фразы никаких отсылок ни к каким контекстам), ни эмпирически (её цитируют по делу и нет, безо всякого контекста, и без мозгов). Хорошая формулировка должна быть самодостаточна, как 2+2=4, как теорема, без необходимости объяснять «что имел в виду автор». А эта фраза, повторюсь, – бред собачий.