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

Компилятор Rust защищает тебя от: Dangling pointers, Use-after-free, Double free, Buffer overflow, Data races, Uninitialized Read.

Компилятор Rust не защищает от Memory leaks и Stack overflow, кроме того нет защиты в unsafe блоках и от OOM.

Переезжать на Neovim это не так просто, хардкорная довольно IDE. Меня пока устраивает VScode. Но планирую.

Да это близко не то. На Rust у тебя код с ошибками памяти просто не соберётся.

Компилятор Rust защищает тебя от: Dangling pointers, Use-after-free, Double free, Buffer overflow, Data races, Uninitialized Read.

То есть не от ошибок выделения памяти, а ровно от того же, от чего защищают примитивы STL на уровне либы, или любой другой либы на Си/Си++, если она построена должным образом? И без необходимости борьбы с бороу черекером? Я правильно понимаю?

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

П.С. Переезжать на неовим достаточно просто, если у тебя есть 20 часов свободного времени.

Ты контекст потерял. Посмотри сообщение, на которое я отвечал.

Покажи мне любую либу на C/C++, которая на 100% гарантирует защиту от: Dangling pointers, Use-after-free, Double free, Buffer overflow, Data races, Uninitialized Read. Частичная защита не годится.

STL тебе чего из этого не гарантирует? Data Races? Мютексы и атомики на месте.

Что за бред? Что значит не дает? Что помешает мне сделать циклические ссылки?

О, дружище.. Чтбы понять глубину сейфити предоставляемоую Растом - достаточно попытаться реализрвать двусвязный список на этом самом Расте. Да, самый обычный. next, prev.

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

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

Ты инфу эту проверил? Ты же неовимом не пользуешься не потому, что попробовал, но тебе не зашло, а потому что НЕ попробовал. Что это за стандарт, если ты стандартно обошёл его? Я вот msvc не пользовался, но мне говорили что это единственная адекватная ИДЕ и дебаггер, несмотря на все минусы и де-факто стандарт в индустриальной разработке. Да, посоны, давайте прислушаемся!

Защита от дурака языком не должна предоставляться. Если вы неправильно проектируете, если вы не понимаете, что такое ownership, если вы «забыли» что у вас указатели где-то повисшие - это просто говорит о том, что вы не достаточно квалифицированный программист. (Не вы лично, это просто оборот такой).

За 27 лет системного программирования я насмотрелся всякого. И теперь с уверенностью говорю, что все ваши use-after-free и прочие ошибки - это , как ни печально, маркер плохого программиста. Хороший программист так не напишет.

Если у вас переполнение буфера - значит вы вообще базовыми правилами разработки пренебрегаете.

Нет. Питон – замечательная вещь для того, чтобы что-то по-быстрому наколхозить (а ещё я благодаря ЛОРу открыл для себя PyCairo, самое то, если надо нарисовать что-то векторное без лишнего мышевазюкания и подгонки).

Проблемы начинаются, когда Питон начинают тащить в средние и большие проекты. Думаю, что и Гвидо сначала не предполагал, что так будут делать.

smart pointers, refcounters, mutexes, etc etc. Все есть, уже лет 25 как. Или около того. Но это ж надо разбираться…

Правильный ответ :). И что мне нравится в Расте - сразу все понятно с первых закор^H^H^H^H конструкций языка.

Ну , сразу же понятно, что это простой двусвязный список?

use std::cell::RefCell;
use std::rc::{Rc, Weak};

type Link<T> = Option<Rc<RefCell<Node<T>>>>;
type Prev<T> = Option<Weak<RefCell<Node<T>>>>;

struct Node<T> {
    value: T,
    prev: Prev<T>,
    next: Link<T>,
}

pub struct LinkedList<T> {
    head: Link<T>,
    tail: Link<T>,
    len: usize,
}

impl<T> LinkedList<T> {
    pub fn new() -> Self {
        Self {
            head: None,
            tail: None,
            len: 0,
        }
    }

    pub fn push_front(&mut self, value: T) {
        let node = Rc::new(RefCell::new(Node {
            value,
            prev: None,
            next: self.head.clone(),
        }));

        match self.head.take() {
            Some(old_head) => {
                old_head.borrow_mut().prev = Some(Rc::downgrade(&node));
                self.head = Some(node);
            }

            None => {
                self.tail = Some(node.clone());
                self.head = Some(node);
            }
        }

        self.len += 1;
    }

    pub fn push_back(&mut self, value: T) {
        let node = Rc::new(RefCell::new(Node {
            value,
            prev: self.tail.as_ref().map(Rc::downgrade),
            next: None,
        }));

        match self.tail.take() {
            Some(old_tail) => {
                old_tail.borrow_mut().next = Some(node.clone());
                self.tail = Some(node);
            }

            None => {
                self.head = Some(node.clone());
                self.tail = Some(node);
            }
        }

        self.len += 1;
    }

    pub fn remove(&mut self, node: &Rc<RefCell<Node<T>>>) {
        let prev = node.borrow().prev.clone();
        let next = node.borrow().next.clone();

        match prev.as_ref().and_then(Weak::upgrade) {
            Some(prev) => {
                prev.borrow_mut().next = next.clone();
            }

            None => {
                self.head = next.clone();
            }
        }

        match next {
            Some(next) => {
                next.borrow_mut().prev = prev;
            }

            None => {
                self.tail = prev.and_then(|p| p.upgrade());
            }
        }

        self.len -= 1;
    }

    pub fn len(&self) -> usize {
        self.len
    }
}

Через гланды, под названием Rc :)

А могли бы. Например, можно отслеживать propagation указателя, который вернула функция аллокации. Если в какой-то момент осталось ноль экземпляров указателя (нет переменных содержащих этот указатель), то вот тут ваш Раст мог бы и ругнуться - потеряли указатель, память утекла. Ну хоть memory leaks у них там memory safe :). Что это вообще такое?!

Проблемы начинаются, когда Питон начинают тащить в средние и большие проекты

С Питон давно завезли аннотацию типов. Документация кода была изначально. Тестовая библиотека давно есть и хорошая. Что ещё надо? Пользуйся всем, чем надо.

Так в этом то и прикол, или ты не понимаешь? Мне вообще не надо возиться с мютексами, атомиками и чем угодно ещё, следить за тем, что бы они были правильно использованы в логике и так далее. Я получаю ровно всё тоже самое, при этом всё это за меня делает borrow checker. То есть всё тоже самое что на уровне «20+ стаж сеньёор на плюсах», только мне это Gemini сгенерил за пять копеек на Flash режиме, и работает, и не падает и не надо баги в рантайме искать. Ты сечёшь или нет? По итогу просто сейчас очень большая часть webdev тусовки прыгнула на Rust, потому что всей этой сишной возни нет, скорость си есть, при этом генерится код даже на самых дешевых моделях запросто. Я об этом ещё в первом сообщении написал, ты просто суть не уловил. Безглючный сишный код без всякой си возни.

Так в том то и суть, что мне не нужно разбираться в этом всё, при этом код работает лучше сеньёрского си кода. Отсюда и популярность Rust.

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

Могли бы. Rust защищает от ошибок Undefined Behavior, а не от ошибок логики. Такова архитектура языка. Ваше право форкнуть и впилить ещё и защиту от утечек памяти и переполнения стека. Аналитические инструменты для отслеживания memory leaks, впрочем в языке имеются.

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

Не надо мне про отступы рассказывать, это удручает.

Если у вас средний-крупный проект, то аннотация типов вводится в приказном порядке. Как и куча других скучных вещей типа документации и тестов. Проблема тут вовсе не в языке.

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

STL тебе чего из этого не гарантирует?

О каких гарантиях идет речь? Для программы с обращением к уже освобожденной памяти:

#include <iostream>
#include <vector>

int main() {
    std::vector<int> v = {42};
    int &a = v[0];
    v.clear();
    v.shrink_to_fit();
    std::cout << "a=" << a << '\n';
    return 0;
}

clang 22.1.8

clang++ --std=c++23 -Wall -Wextra -Wpedantic --analyze -Xanalyzer -analyzer-output=text

и gcc 16.2.1

g++ --std=c++23 -Wall -Wextra -Wpedantic -fanalyzer

не показали никаких предупреждений.

Кстати, раз уж мы на Linux форуме (вроде бы, по крайней мере он, вроде, так называется), то я до вашего сведенья довожу, что принципиально схожая с моей - позиция у Линуса Торвальдса, что Rust это круто и использовать ИИ для генерации кода это тоже круто. Так вот.

со сборщиком мусора

У меня даже такая гипотеза родилась - те, кто с указателями и памятью не умеет - они назвают память мусором :).

Это довольно искусственный пример.

В реальности же в таких случаях пользуются refcounterами. Элемент массива, на который вы взяли указатель - должен быть refcountable объектом\структурой. Тогда все будет хорошо. И из массива элемент удалится, и ссылка на него не будет висячей.

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

Массив указателей не бесплатен по нагрузке на память и процессор, применять его не всегда уместно.

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

void func_a(const struct_b &s) {
    func_c();
    printf("%d\n", s.field_d);
}

долго работала без проблем, через некоторое время был добален кэш из элементов типа struct_b, который сбрасывался в func_c, все продолжало хорошо работать пока однажды в новом коде не вызвали func_a с элементом взятым из этого кэша.

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

Вы знаете, я вот изучал недавно реализацию WiFi драйвера написанную на Rust. Так вот там все состоит из unsafe.

При написании кода на Rust - они просто отсутствуют.

Раст без санитайзеров все равно использовать нельзя. Из-за unsafe. А на C++ мы и так пользуемся санитайзерами..

Ну это вообще ожидаемая проблема когда скриптописатели решили попрограммировать. Как впрочем и вообще категорическое непонимание того, что у любого объекта есть время жизни и надо это держать в голове.

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

Ну и Линус, если уж на то пошло, говорил не совсем так. Линус всегда был жёстким прагматиком, и для него всё, тобой перечисленное – это инструменты. Не менее, но и не более. И тот же Раст 3 года щупали и проверяли, прежде чем он стал разрешённым языком для разработки ядра.

А на C++ мы и так пользуемся санитайзерами..

А вот Си лучше всех - в нём никакие санитайзеры не нужны (по крайней мере я без них прекрасно обхожусь).

Если у вас так хорошо с этим пониманием, то почему 90% патчей для всего, что написано на C/C++ - это исправление ошибок памяти? Выходит как-то не очень с пониманием? Получается, что у компилятора Rust как-то лучше с этим понимаем, чем у среднестатистического C/C++, как вы выражаетесь, «программиста», если в Rust все ошибки просто по умолчанию исключены на этапе компиляции?

Торвальдс на днях буквально сказал: «не нравится код сгенерированный ИИ - валите из разработки Linux».

90% патчей для всего, что написано на C/C++ - это исправление ошибок памят

Пруф?

Пруф?..

Можно вопрос, почему ты психуешь? Я в довольно вежливой форме написал, что Neovim - стандарт для разработки на Rust, что есть попросту устоявшийся факт. Да, я им не пользуюсь, потому что это хардкорная IDE для ценителей, а я пишу далеко не только на Rust, и пока руки не дошли его освоить. У тебя началась какая-то истерика касательно данного топика. Я просто не понимаю, у тебя психика что-ли расшатанная?

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

Полная цитата Торвальдса с выступления:

I realize that some people really dislike AI, but this is an area where I’m willing to absolutely put my foot down as the top-level maintainer. Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away. AI is a tool, just like other tools we use. And it’s clearly a useful one. It may not have been that «clearly» even just a year ago, but it’s no longer in question today. There are other questions around AI (like what the economy of it will actually look like in the end), but «is it useful» is no longer one of those questions. Anybody who doubts that clearly hasn’t actually used it. Yes, it can also be a somewhat painful tool, both for maintainer workloads and just from a «it keeps finding embarrassing bugs» standpoint. But the solution is not to put your head in the sand and sing «La La La, I can’t hear you» at the top of your voice like some people seem to do. The solution is to make sure those LLM tools help maintainers instead of just causing them pain. There’s no question on that side. We’re not forcing anybody to use it, but I will very loudly ignore people who try to argue against other people from using it. And no, AI isn’t perfect. But Christ, anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time. Because it’s not like natural intelligence is always all that great either. The kernel project has been and will continue to be about the technology. Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that’s a side benefit, not the point of the project. This is NOT some kind of «social warrior» project, never has been, and never will be. In the kernel community we do open source because it results in better technology, not because of religious reasons. And so we make decisions primarily based on technical merit. Not fear of new tools.

ну вообще, neovim это не стандарт для разработки на rust, как и не стандарт впринципе. всеми этими vim/emacs пользуется меньшинство программистов. самый популярный редактор кода у растаманов - vscode

Если у вас переполнение буфера - значит вы вообще базовыми правилами разработки пренебрегаете.

Масштабы проектов, внезапно, бывают разные.

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

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

Я не знаю как в рунете обстановка, стараюсь в русском интернете особо не сидеть (по данному треду, в целом, видно почему), в англоязычном интернете почти все на Neovim сидят, аналогично со всеми топовыми Rust-ютуберами. От русского интернета в практическом плане толку очень мало, может здесь и какая-то другая статистика. Мне, если честно - вообще всё равно.

Можно! А какую часть моего сообщения ты называешь психованием?

Я ещё раз вам объясняю своё мнение. Я из мира языков со сборщиком мусора. Подавляющее большинство программистов на планете пишет на языках со сборщиками мусора. Так называемое «прикладное программирование». Да, для меня и для всех нас, Rust - это просто подарок и нечто великолепное. Такое мнение у многих. Почему, например, Торвальдс такой верный приверженец Rust? Да по простой причине, что когда ты основной ментейнер ядра Linux (а не одно специфическое приложение пилишь и поддерживаешь двадцать пять лет) - то тебе, естественно, будет очень нравится концепция языка, который избавляет тебя от проблем с ошибками неопределенного поведения, что, по сути, съедает 90% ресурса разработки на любом крупном проекте. То есть, теперь - ты можешь потратить эти 90% ресурса на улучшение логики, а не на борьбу с ошибками неопределенного поведения. То, есть мы все, прикладные программисты и все прочие, кто не копается в распределении памяти 90% своего времени (включая системных архитекторов, вроде Торвальдса) - получили в своё распоряжение инструмент, который позволяет мне выдавать код написанный на системном языке, наравне с вашим (даже лучше), и это при том, что у вас 27 лет опыт системного программирования, а у меня ноль. Собственно, есть ещё вопросы о плюсах Rust и зачем он нужен?

в англоязычном интернете

Тоже непринято распространять непроверенную и ложную информацию с уверенным видом, разве нет?

Что тебе всё равно — видно.

Ты этот «общеизвестный факт» откуда почерпнул? Или у тебя самого достаточно экспертизы в це/цепепе чтобы делать такие громкие заявления?