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

Да? А как просмотреть код для его проверки на закладки?

Открыть в песочнице.

То, что VSCode, непример, предлагает в качестве ограничений - это не песочница. Это издевательство. Если взять тот же rust-analyzer, то без него не будут работать автодополнение, поиск по типам и определениям и многое другое. В таком режиме пытаться что-то анализировать, равносильно запуску grep и обычному просмотру кода в vim. Просто нет смысла использовать IDE.

Впрочем, это не проблема именно rust, схожая ситуация для golang и python. Но для последних хотя бы можно привинтить ctags и использовать его в vim. Для rust оно не работает и надо ставить сторонние утилиты через тот же cargo(а мы ведь ему не доверяем). Хотя, может, сейчас и стало лучше, хз. Но когда мне последний раз приходилось с этим сталкиваться, было именно так.

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

Но, нет. В VSCode если ты добавил проект в Trusted Workspace, то всё, что там обновляется уже по умолчанию доверено.

С другими IDE не работал и не собираюсь. Как и очень большое количество разработчиков. Тут или где-то в соседнем треде как раз сегодня кто-то приводил ссылку на наиболее используемые IDE для rust и VSCode там был в тройке лидеров.

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

Кто такое сказал? В коде бывают очень неочевидные связи, тем более что код для новых фич может требовать изменений в старом.

при ребейзе своих наработок надо проверять результат

Т.е. начинать все проверки с нуля.

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

для этих 0.001% индустрии

Это далеко не 0.001% индустрии. Это любой гигант в IT, у которого внезапно больше всего вакансий и сотрудников.

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

Современный код на с++, написанный с учётом вопросов безопасности

Статистика хрома 70% багов в Chrome из-за неверной работы с памятью Где еще современнее и безопаснее то искать?)

Это далеко не 0.001% индустрии. Это любой гигант в IT, у которого внезапно больше всего вакансий и сотрудников.

Даже у любого гиганта отнюдь не весь код настолько высококритичен. А из высококритичного кода отнюдь не весь должен быть высокопроизводительным и высоконагруженным. Во многих остальных случаях те же практические задачи дешевле и проще решаются средствами Java, Go, Python, PHP, C# и проч., а инженерный ригоризм Rust превращается из преимущества в издержку. Так что да, есть какая-то область где нужно извращаться, где все звёзды сошлись, но она весьма ограничена.

Статистика хрома 70% багов в Chrome из-за неверной работы с памятью Где еще современнее и безопаснее то искать?)

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

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

Ты про переписывание cp с ошибками в логике обработки аргументов командной строки?

И?

А и да. Где этот сказочный «Современный код на с++, написанный с учётом вопросов безопасности»? А то в реальной жизни почемуто софт на крестах лажает с памятью.

Где этот сказочный «Современный код на с++, написанный с учётом вопросов безопасности»?

libxml это старая сишная библиотека, но я говорю не только о возрасте и языке.

Взять например, Qt. Хотя это вроде бы современная библиотека, она использует подходы ещё с++98. Там нет ни unique_ptr, ни shared_ptr, std::span и многое другое.

И таких зрелых с++ библиотек большинство. Новых, написанных с современным подходом пока исчезающе мало, а старые типа Qt никто не спешит переписывать.

Современный с++ существенно отличается от этого старого подхода. Но известных популярных библиотек на нём не сильно больше (а то и меньше), чем на расте. Это же, уверен, относится и к гугловскому коду и другим исследованиям.

Новых, написанных с современным подходом пока исчезающе мало, а старые типа Qt никто не спешит переписывать

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

Нашёл на кого равняться... Хром (и вообще большинство гугловской деятельности) это пример того как делать не надо.

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

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

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

Там нет ни unique_ptr, ни shared_ptr, std::span и многое другое.

У вас устаревшая на несколько лет информация. Сам unique_ptr не используется в публичном интерфейсе, насколько я помню, но его использование поощряется, а соответствующие умные указатели Qt частично объявлены устаревшими. Всякие string_view и span как минимум принимаются в конструкторах.

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

Меня пугает подсяет ссылок в связном списке

требует от программиста некоторых приседаний при написании кода

Когда код начнёшь не только писать и компилировать, но и запускать, тогда и почувствуешь разницу.

Это дословно именно то, что я и так сейчас имею, но на Си.

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

Ну штош теперт. Для таких , как вы, __prefetch() придумали в GCC, подсасывать в кэш то, что нужно.

Вот твой префетч из гцц, void __builtin_prefetch (const void *addr, ...), видишь там адрес в аргументах? В обычном связном списке адрес следующего элемента ты узнаёшь только после того, как загрузил текущий элемент и прочитал из него следующий. Сам pointer chasing на месте, префетч не поможет. А если у тебя адреса будущих элементов известны сильно заранее, то у тебя уже есть какой-то дополнительный механизм их хранения/индексации, и это уже не просто обычный обход списка по next. Да и куда красота твоей сишки денется, если ты будешь компиляторозависимыми костылями его обмазывать?

В реальном мире списки кругом: ваша сетевая карта, допустим Ethernet

Вот тут уже просто мимо. У Ethernet типичная схема RX/TX descriptor rings. Специально глянул в доку. В памяти это может быть обычный массив дескрипторов [desc0][desc1][desc2][desc3], а следующий элемент выбирается по индексу. Это не связный список. Покажи конкретный драйвер, где на списках построено, потыкаю.

PS: Мне было бы реально интересно посмотреть на реализацию какого-нибудь более-менее живого TCP/IP стека на Rust. Есть такое? Интересно поглазеть, как у них будет выглядеть работа с памятью.

Да, сетевой стек фучии полностью написан на расте, вот тут сырцы: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/main/src/connectivity/network/netstack3

Вопросики, вопросики.

Резонные вопросики, в питонячьем мире этого конечно сильно больше и там они сильно взрослее. Но для чебуречной не нужны особо сложные опенапи фичи, чтобы куцая по меркам питона растовая тулза на них спасовала, в любом случае условный кодекс нагенерит тебе это на ать-два. Зато тулинг питона более замороченный, пока там все эти uv/poetry настроишь, mypy+ruff (хз нужно ли для чебуречной), а потом еще в CI это все запихнешь… В расте все в одном месте, и билдится в статичный бинарь. Короче, что я хочу сказать, для вебдева использовать раст - не бредовая мысль, это не то же самое что и на сях.

У вас устаревшая на несколько лет информация.

В смысле устаревшая?

Вот тебе официальный пример из Qt6

https://code.qt.io/cgit/qt/qtbase.git/tree/examples/opengl/2dpainting/window.cpp?h=6.11

Cтарые добрые голые (или сырые? как лучше rawptr перевести?) указатели

C++98 во всей своей красе…

Что плохого в unsafe? Это часть языка, и это не полная свобода. Вот единственное с чего снимает ошейник unsafe:

• Разыменовывать сырой указатель
• Вызывать unsafe-функцию или метод
• Получать доступ к изменяемой статической переменной или изменять её
• Реализовывать unsafe-трейт
• Получать доступ к полям union

по-прежнему работают:

• Проверка типов
• Бороу чекер для обычных &T/&mut T
• Правила move/ownership
• Проверки lifetime там, где они выражены обычными ссылками
• Trait checking
• Visibility/privacy
• Pattern matching/exhaustiveness
• Обычные правила мутабельности

Как видишь даже unsafe rust остается более безопасным чем сишка.

Что плохого в unsafe?

Сама идея (не)безопасного режима очень хороша, в том или ином виде это непременно попадёт в с++, надеюсь раньше чем его похоронят. :) За первую реализацию этой идеи следует сказать спасибо расту и его авторам.

Там как раз все обмазано списками, односвязными.

Односвязный список в расте реализуется вообще без unsafe.

Ну так тут владение и не предусматривается. Какой же ещё указатель использовать? В рамках Qt только QPointer будет подходящей заменой.

непременно попадёт в с++

Не попадёт. Или же он потеряет обратную совместимость, а значит автоматом станет не нужным.

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

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

УПД. А пердолинг связан с непониманием концепции языка как такового. Имхо.

Это всё здорово и прекрасно, но мы говорим о вполне конкретном показателе — скорости разработки

Основная идея QPointer для qobject и графических виджетов вполне подходит: вполне логично, что у виджета есть виджет-родитель-владелец, который им владеет. Но всё что происходит вокруг этого, и в кютном api и внутри Qt - всё это написано на старом c++98. И полностью переделать это без частичного отказа от совместимости не получится.

С современном с++ владение виджетом(или другим объектом) логично выражать либо через unique_ptr, либо непосредственно через «член класса». Гарантированный не владеющий доступ - через ссылку&. Если возможен нуль, то нужен отдельный тип. Там где действительно совместное владение, то shared_ptr, weak_ptr, вот это вот всё. Конкретный пример: сейчас можно написать

QPushButton quit("Quit");
QWidget window;
quit.setParent(&window);

Это ошибочный код. window попытается удалить quit в деструкторе и мы получим UB. Но с помощью современного с++ можно сделать api который не позволит сделать ошибку:

QWidget window;
auto& quit = window.makeChild<QPushButton>("Quit");

Либо с помощью unique_ptr:

QWidget window;
auto quit = std::make_unique<QPushButton>("Quit");
window.addChild(std::move(quit));

И таких примеров в Qt очень много. Он остаётся с++98 и внутри и в api, хотя пользователь его может использовать с современными лямбдами, концептами и range for…

Но сам он преимущества современного с++ для управления временем жизни/владением объектом не использует. Современный же с++ уже позволяет создавать безопасный api, который делает многие классы ошибок невозможными или существенно менее вероятными. 100% гарантий как раст на все случаи жизни он не даст, но все практически значимые ситуации покрыть можно.

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

Новые библиотеки и новый код, написанный с учётом требований безопасности на современном с++ значительно снижает риски. И развитие в этом направлении продолжается, с каждым новым стандартом ситуация улучшается и будет улучшаться.

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

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

Там по ощущениям меньше сотни строк кода. Это много? Покажи аналогичную реализацию на крестах.

Наглядность, простота, понятность - вот что главное. Объём кода это тоже существенно. Лишний код дольше читать, дольше писать, труднее понять.

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

Попросил жптшку этот растокод переписать на с++, хотя по-моему и так всё очевидно, но может тебе так будет наглядней

#include <cstddef>

template <typename T>
class LinkedList
{
    struct Node {
        T value;
        Node* prev = nullptr;
        Node* next = nullptr;
    };

public:
    LinkedList() = default;

    ~LinkedList() {
        clear();
    }

    void push_front(const T& value) {
        Node* node = new Node{
            .value = value,
            .prev = nullptr,
            .next = head_
        };

        if (head_) {
            head_->prev = node;
        } else {
            tail_ = node;
        }

        head_ = node;
        ++len_;
    }

    void push_back(const T& value) {
        Node* node = new Node{
            .value = value,
            .prev = tail_,
            .next = nullptr
        };

        if (tail_) {
            tail_->next = node;
        } else {
            head_ = node;
        }

        tail_ = node;
        ++len_;
    }

    void remove(Node* node) {
        if (node->prev) {
            node->prev->next = node->next;
        } else {
            head_ = node->next;
        }

        if (node->next) {
            node->next->prev = node->prev;
        } else {
            tail_ = node->prev;
        }

        delete node;
        --len_;
    }

    std::size_t size() const {
        return len_;
    }

    void clear() {
        Node* p = head_;

        while (p) {
            Node* next = p->next;
            delete p;
            p = next;
        }

        head_ = nullptr;
        tail_ = nullptr;
        len_ = 0;
    }

private:
    Node* head_ = nullptr;
    Node* tail_ = nullptr;
    std::size_t len_ = 0;
};

Это ни фига не аналог, и не читабельнее и, самое главное, не надёжней. Аналог должен быть с каким-нибудь std::shared_ptr вместо указателей. Так то в расте тоже сырые указатели есть (которые тоже лучше обставлены и реализованы чем в сишках/плюсишках), и идиоматичнее реализовывать именно на них, это если, конечно, прям всралась интрузивно-указательная реализация списка. Как это и сделано в стандартно библиотечном LinkedList https://doc.rust-lang.org/src/alloc/collections/linked_list.rs.html#50-53

А с сями-то что не так? У меня сайт чебуречной на сях. Есть не просит.

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

может быть не в пользу плюсов.

Вот я о том же. Откуда знаем-то? Может быть, а может быть и наоборот.

С современном с++ владение виджетом(или другим объектом) логично выражать либо через unique_ptr, либо непосредственно через «член класса».

Либо через индекс на элемент пула, либо через указатель на память где-то, либо…

Да куча вариантов в зависимости от задачи.

QWidget window;
auto quit = std::make_unique<QPushButton>("Quit");
window.addChild(std::move(quit));

Таких примеров лучше поменьше.

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

Та же сотня строк. Мне понятны оба варианта.

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

Это ни фига не аналог, и не читабельнее и, самое главное, не надёжней.

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

дело не в объёме, хотя с++ версия явно более краткая

что не так?

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

У меня другой опыт, но это не принципиально. Тут нам интересно сравнение двух подходов.

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

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

Для списка больших объектов

а в принципе он используется, например для организации LRU-кэш, intrusive list (это у меня было, но есть и в ядре), потом для кольца я его использовал, да всё уже и не вспомню.

Кстати, точно! С кольцом особенно интересно, особенно в контексте Раст, там же получается цикл в графе, хотелось бы посмотреть на имплементацию в Расте! Гы-гы

Бесполезные вещи на ровном месте

Двусвязный список? Какой-нибудь lru кэш, например. Не в такой реализации, конечно

скорости разработки

Скорость отладки включаем или нет?