Вышла новая версия статического анализатора кода cppcheck 2.7, позволяющего выявлять различные классы ошибок в коде на языках Си и Си++,...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56661
а есть что-то подобное для раста? для выявления утечек памяти и всего такого -- в общем типичных проблем растокода
> для выявления утечек памяти и всего такого -- в общем типичных проблем растокодаА ты хорош!
Но если серьёзно, cppcheck -- это так себе решение в сравнении с каким-нибудь Coverity, тем анализатором с Хабра или даже clang-analyzer.
Линтеры есть, тот же clippy. Но я ненастоящий растоман, за качество инструментов ничего говорить не буду
Отличный компактный инструментковертли вообще монстр, да еще и платный, да еще и сложный в настройке
анализатор с хабра пора выбросит на помойку
кланг анализер не все находит что сабж, но для сильно подробных разборов полётов, кланг анализер показывает
весь контрол флов
Да лан, надо отдать должное этим чувакам, они свой пивас затолкали даже интолу, вроде?!Из природной брезгливости к проприетарщине, я не пробовал пивас. Ничего не скажу. Но упорство с которым они затолкали его кому-то в интоле, мелкомягким, эт нечто.
У коверити есть бесплатный CI для свободных проектов.
Я так и не смог найти каких-нибудь инструментов для раста. Память просто вытекает _куда-то_, исполнение просто зависает _почему-то_, но зато без проблем с кодом. Может быть стоит подождать и баги ллвм исправят, тогда то точно всё будет работать как надо.
Ах да, ещё вечные проблемы с синхронизацией мультипотока в расте ударили с новой силой. Да я смотрю и жырнолисе косяки синхронизации табов полезли как вебрендер на расте впихнули, хотя, казалось бы, главный и единственный пользователь раста должен понимать, что к чему. Отсутствие инструментов для отладки делает ситуацию куда хуже чем с привычными проблемами плюсов.
Ты наркоман что ли? Какое отношение веб-рендер имеет к синку табов?
Табы отваливаются из-за вебрендера, не иначе. Это проявляется как глюки отрисовки при попытке скроллить и глюки интерфейса, можно переключить на соседний таб в другом контентном процессе и там всё нормально, он не теряется. Если бы можно было прибить контентный процесс я бы не жаловался, но при этом весь интерфейс перестаёт нормально работать и единственное решение это перезапуск. До вебрендера такого точно не было. Проявляется чаще всего когда таб возвращается из свопа.А ещё периодически начинает жрать в 5 раз больше ресурсов, будто включился программный режим вебрендера, только хуже. Я настроил так, чтобы он не включался, можно сделать вывод, что раст игнорирует настройки.
На самом деле вопрос надо ставить не так. "Есть ли для C++ такие анализаторы, которые ищут проблемы с памятью так же хорошо как базовый синтакс Rust". И ответ - нет.
https://nvd.nist.gov/vuln/detail/CVE-2018-1000810https://nvd.nist.gov/vuln/detail/CVE-2021-28875
- Ну что, сынку, помог тебе твой раст?
P.S. Банально первые ссылки из гугла.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rustБезопастност.
Вродебы раст позиционируется как штука которая исключит подобные ошибки.CVE-2021-45715 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_window_function has a use-after-free.
> Вродебы раст позиционируется как штука которая исключит подобные ошибки.
> CVE-2021-45715 An issue was discovered in the rusqlite crate 0.25.x before
> 0.25.4 and 0.26.x before 0.26.2 for Rust. create_window_function has a use-after-free.Пропаганда. Смотри:
https://github.com/jeromefroe/lru-rs/pull/121
Уязвимость тянется отсюда:
https://github.com/jeromefroe/lru-rs/issues/120
Как видишь, просто, без рук и ансейфа, как там ниже анон возмущается.
> https://github.com/jeromefroe/lru-rs/issues/120
> Как видишь, просто, без рук и ансейфа, как там ниже анон возмущается.Прекращай смотреть опой:
#![no_std]
...
- pub fn iter<'a>(&'_ self) -> Iter<'a, K, V> {
+ pub fn iter(&self) -> Iter<'_, K, V> {
Iter {
len: self.len(),
ptr: unsafe { (*self.head).next },
Дык давайте тогда с C++ и C сравним. Вот где безопасность должна быть. Все-таки 40 лет разработки.
Но ведь "базовый синтаксис раст", май эс. ;)Сравнивать с цэ? Пожалуйста. С цэпэпэ - пожалуйста. С цэ/цэпэпэ - вам не кажется что это неадекватно? :-D
Ну и положа руку на сердце, не думаете что тех CVE как-то слишком уж многовато для такого малоиспользуемого и маргинального языка? Ну, в сравнении с сишкой из 70х, и цэпэпэ, у которых петабайты исходного кода. Ммм?
Внезапно, да, помог. Хочешь писать безопасно? Лови небольшие оверхеды и используй unsafe. Хочешь быстро? Следи за своим кодом сам. Что не так?
> И ответ - нет.Обосновать свой громки пук опеннетный эксперт, разумеется, не потрудился.
Если для практики, а не меряться "кто круче" - то вообще тривиально. Банальная проверка на отсутствие сырых указателей как членов класса и создания умных указателей из сырых (а не с помощью make_unique()/make_shared()) и арифметики с указателями вне begin() и end() вылечит 99% проблем. Остаётся ещё всякий bounds checking по вычисленным индексам - но это в прицнипе в компайл-тайме не ловится, а в рантайме адски дорого.Останется небольшая доля нетривиальных извращений, которые в любом случае надо ревьюить, так как там больше вопросов будет не по управлению памятью, а покоррктности алгоритмикив целом (всякие кастомные аллокаторы в основном).
Другими словами - пишете код в рекомендованном современном плюсовом стиле, а не так, как привыкли до 11-го года - и нет проблем.
в раст все работает из коробки
раст даже пишет код за тебя
неважно как и какой код написал раст программа будет работать так как ты задумал в голове. это не магия это раст.
Нет, по сути язык заставляет писать код, который проходит его внутренний линтер (в его случае линтер следить за владением объектов). Так что априори код безопаснее, чем C++, где компилится даже откровенно бредовый код, который должен просто быть синтаксически верным. Т.е. можете просто написать код, который в бесконечном цикле выделяет через new память и не освобождает. И вам для этого даже не надо писать хаки, фича доступна из коробки.
> Нет, по сути язык заставляет писать код,Ты не уловил суть. Она намного глубже - извечная битва (не путать с клоунадой) против Расто-Зла!
Есть древняя легенда, сотканна в поэму,
Дошла до нас сквозь вереницы лет,
Как-то зайдя на Опеннет, Воен-за-Си увидел Расто-тему
Там мерзкий Раст бесстыже был воспет!
Свой Боевой Пукан вперед направив,
Воен открыто пукнyл во Врага!
Но Растоман, не соблюдая честных правил
В ответ плеснул вонючим смузи сподтишка.
Воен едва, лишь чудом увернулся,
Ему по сути просто повезло ...
Вот с той поры Воены сражаются и срутся,
И много тонн овна по форуму стекло.
Пусть кажется, что Воены побеждают,
Не будет скоро в мире Расто-Зла,
Но Растоманы, паскуды, никак не умирают,
Что раскаляет Военов пуканчик до красна!
>который проходит его внутренний линтер (в его случае линтер следить за владением объектов).Да что-то как-то не особо то и следит.
CVE-2021-45719 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. update_hook has a use-after-free.
CVE-2021-45718 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. rollback_hook has a use-after-free.
CVE-2021-45717 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. commit_hook has a use-after-free.
CVE-2021-45716 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_collation has a use-after-free.
CVE-2021-45715 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_window_function has a use-after-free.
CVE-2021-45714 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_aggregate_function has a use-after-free.
CVE-2021-45713 An issue was discovered in the rusqlite crate 0.25.x before 0.25.4 and 0.26.x before 0.26.2 for Rust. create_scalar_function has a use-after-free.
>>который проходит его внутренний линтер (в его случае линтер следить за владением объектов).
> Да что-то как-то не особо то и следит.
> CVE-2021-45719 An issue was discovered in the rusqlite crate 0.25.x before
> 0.25.4 and 0.26.x before 0.26.2 for Rust. update_hook has a use-after-free.https://github.com/rusqlite/rusqlite/pull/1049/commits/42605...
+16,9 @@ unsafe extern "C" fn free_boxed_value<T>(p: *mut c_void) {
impl Connection {
...
> {unsafe extern "C" fn call_boxed_closure<C>(
arg1: *mut c_void,
Какой громкий пук ...
Получается без unsafe ничего на Rust кроме Hello World не написать.
> Получается без unsafe ничего на Rust кроме Hello World не написать.Получается, если из раста коснуться внешнего г.вна, написанного на си - всё превращается в г.вно. Си - этакий современный царь Мидас, только чаще превращает не в золото. А не взаимодействовать с уже написанными петабайами сишного г.вна не всегда получается - даже ядро линукса на нем написано. Но это не на долго, работы в этом направлении начаты...
>> Получается без unsafe ничего на Rust кроме Hello World не написать.
> Получается, если из раста коснуться внешнего г.вна, написанного на си - всё
> превращается в г.вно. Си - этакий современный царь Мидас, только чаще
> превращает не в золото. А не взаимодействовать с уже написанными петабайами
> сишного г.вна не всегда получается - даже ядро линукса на нем
> написано. Но это не на долго, работы в этом направлении начаты...А что скажешь на это:
https://github.com/jeromefroe/lru-rs/issues/120
Тоже си нахрапел вам в штаны? :-D
Какой чудный раст!
> А что скажешь на это:
> https://github.com/jeromefroe/lru-rs/issues/120
> Тоже си нахрапел вам в штаны? :-Dhttps://github.com/jeromefroe/lru-rs/commit/3c6fdf07a4ab58f6...
#![no_std]
...
- pub fn iter<'a>(&'_ self) -> Iter<'a, K, V> {
+ pub fn iter(&self) -> Iter<'_, K, V> {
Iter {
len: self.len(),
ptr: unsafe { (*self.head).next },Какой унылый спрыг.
> из раста коснуться внешнегоА что, раст ни для чего не подходит, кроме как написания обёрток вокруг Си?!
>>> rusqlite
>>> wrapper for using SQLite from Rust.
>> из раста коснуться внешнего
> А что, раст ни для чего не подходит, кроме как написания обёрток вокруг Си?!Кончай уже газифицировать лужи.
>> из раста коснуться внешнего
> А что, раст ни для чего не подходит, кроме как написания обёрток
> вокруг Си?!Там выше пример, как и без оберток вокруг си можно в расте плодить уязвимости.
...а потом оказывается, что вы пишете программу для тестирования работы OOM киллера.Что характерно - написать бесконечный цикл, тыпо выделяющий память (ну в виде создания объектов, например) можно вообюще на любом языке.
В компилятор встроен - одна половина MIR, вторая половина в официальном крейте Miri https://github.com/rust-lang/miri#bugs-found-by-miri
Есть еще tsan https://github.com/tokio-rs/loom
Miri
Пользуются ли ей разработчики KDE?
Отличный и крайне недооцененный проект. Жалко что им так мало пользуются.
много кто пользуется
Сильно много ложных срабатываний.
Отличный. Когда-то даже удивился, увидев его враппер в исходниках wireshark'a. Инструмент оцененный теми, кому надо. Вот бы еще разраб сделал нормальный ман, вместо этого генерируемого убожества... просто же, ну, или, если удобно так -- добавлять в дист сгенеренный ман, как принято у аристократии...
>> Добавлена поддержка представлений (view) контейнеров - в тег библиотеки добавлен атрибут view, указывающий, что класс является представлением. Код анализа времени жизни обновлён для использования данного атрибута при поиске "висячих" контейнеров;Когда я изучал С++ там не было ни вью, ни контейнеров. Тем более висячих.
Когда я изучал C++ не было ... так что и ну его нафиг
Когда Я изучал, С++ еще не было..
я ждал что ктото это напишет. такие вы пупсики
странные ощущения оставляет. как будто зря каждый раз жру кактус чтобы его настроить, а выдача как от модных варнингов гцц. (про си)
Описание к третьей ссылке поправьте. Во-первых, MIRSA - это не стиль оформления кода. Во-вторых, в cppcheck нет проверок стилей оформления кода.
Им посрать.
Подскажите пожалуйста, как это лучше назвать? Стиль кодирования? Правила кодирования?
Правописание.
Что-то подсказывает мне, что donate-cpu.py имеет в зависимостях donate-bandwidth.py...
Не надо. Далее стандартные средства студии находят больше, чем это.