The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск cppcheck 2.7, статического анализатора кода для языков C++ и С

08.02.2022 13:47

Вышла новая версия статического анализатора кода cppcheck 2.7, позволяющего выявлять различные классы ошибок в коде на языках Си и Си++, в том числе при использовании нестандартного синтаксиса, типичного для встраиваемых систем. Предоставляется коллекция плагинов, через которые обеспечена интеграция cppcheck с различными системами разработки, непрерывной интеграции и тестирования, а также предоставлены такие возможности как проверка соответствия кода стилю оформления кода. Для разбора кода может применяться как собственный парсер, так и внешний парсер от Clang. В состав также входит скрипт donate-cpu.py для предоставления локальных ресурсов для выполнения работы по совместной проверке кода пакетов Debian. Исходные тексты проекта распространяются под лицензией GPLv3.

Развитие cppcheck сосредоточено на выявлении проблем, связанных с неопределённым поведением и применением конструкций, опасных с точки зрения безопасности. Целью также является минимизация ложных срабатываний. Среди выявляемых проблем: указатели на несуществующие объекты, деления на ноль, целочисленные переполнения, некорректные операции битового сдвига, некорректные преобразования, проблемы при работе с памятью, некорректное использование STL, разыменование нулевых указателей, применение проверок после фактического обращения к буферу, выход за границы буферов, использование неинициализированных переменных.

Параллельно шведской фирмой Cppcheck Solutions AB разрабатывается расширенная версия Cppcheck Premium, обеспечивающая анализ наличия бесконечных циклов, улучшенный поиск неинициализированных переменных и расширенный анализ переполнения буферов.

В новой версии:

  • Добавлена поддержка представлений (view) контейнеров - в тег библиотеки добавлен атрибут view, указывающий, что класс является представлением. Код анализа времени жизни обновлён для использования данного атрибута при поиске "висячих" контейнеров;
  • Улучшены проверки;
  • Исправлены накопившиеся ошибки и устранены недоработки анализатора.


  1. Главная ссылка к новости (https://github.com/danmar/cppc...)
  2. OpenNews: Выпуск cppcheck 2.6, статического анализатора кода для языков C++ и С
  3. OpenNews: Выпуск PHPStan 1.0, статического анализатора для кода на языке PHP
  4. OpenNews: Facebook открыл код статического анализатора Mariana Trench
  5. OpenNews: Facebook представил Pysa, статический анализатор для языка Python
  6. OpenNews: Релиз свободного статического анализатора кода frama-clang 0.0.5
Автор новости: Совершенно другой аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/56661-cppcheck
Ключевые слова: cppcheck
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (53) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 16:20, 08/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    а есть что-то подобное для раста? для выявления утечек памяти и всего такого -- в общем типичных проблем растокода
     
     
  • 2.4, topin89 (ok), 17:02, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > для выявления утечек памяти и всего такого -- в общем типичных проблем растокода

    А ты хорош!

    Но если серьёзно, cppcheck -- это так себе решение в сравнении с каким-нибудь Coverity, тем анализатором с Хабра или даже clang-analyzer.

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

     
     
  • 3.15, Аноним (15), 19:32, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Отличный компактный инструмент

    ковертли вообще монстр, да еще и платный, да еще и сложный в настройке

    анализатор с хабра пора выбросит на помойку

    кланг анализер не все находит что сабж, но для сильно подробных разборов полётов, кланг анализер показывает
    весь контрол флов

     
     
  • 4.22, Самокатофил (?), 20:28, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да лан, надо отдать должное этим чувакам, они свой пивас затолкали даже интолу, вроде?!

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

     
  • 4.29, Аноним (29), 21:59, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    У коверити есть бесплатный CI для свободных проектов.
     
  • 2.6, Аноним (6), 17:16, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Я так и не смог найти каких-нибудь инструментов для раста. Память просто вытекает _куда-то_, исполнение просто зависает _почему-то_, но зато без проблем с кодом. Может быть стоит подождать и баги ллвм исправят, тогда то точно всё будет работать как надо.
     
     
  • 3.8, Аноним (6), 17:28, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ах да, ещё вечные проблемы с синхронизацией мультипотока в расте ударили с новой силой. Да я смотрю и жырнолисе косяки синхронизации табов полезли как вебрендер на расте впихнули, хотя, казалось бы, главный и единственный пользователь раста должен понимать, что к чему. Отсутствие инструментов для отладки делает ситуацию куда хуже чем с привычными проблемами плюсов.
     
     
  • 4.10, Анонн (?), 18:15, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Ты наркоман что ли? Какое отношение веб-рендер имеет к синку табов?
     
     
  • 5.11, Аноним (6), 18:36, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Табы отваливаются из-за вебрендера, не иначе. Это проявляется как глюки отрисовки при попытке скроллить и глюки интерфейса, можно переключить на соседний таб в другом контентном процессе и там всё  нормально, он не теряется. Если бы можно было прибить контентный процесс я бы не жаловался, но при этом весь интерфейс перестаёт нормально работать и единственное решение это перезапуск. До вебрендера такого точно не было. Проявляется чаще всего когда таб возвращается из свопа.

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

     
  • 2.18, Alexey (??), 20:06, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    На самом деле вопрос надо ставить не так. "Есть ли для C++ такие анализаторы, которые ищут проблемы с памятью так же хорошо как базовый синтакс Rust". И ответ - нет.
     
     
  • 3.21, Самокатофил (?), 20:23, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    https://nvd.nist.gov/vuln/detail/CVE-2018-1000810

    https://nvd.nist.gov/vuln/detail/CVE-2021-28875

    - Ну что, сынку, помог тебе твой раст?

    P.S. Банально первые ссылки из гугла.

     
     
  • 4.23, Самокатофил (?), 20:29, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

    Безопастност.

     
     
  • 5.38, Аноним (38), 08:38, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Вродебы раст позиционируется как штука которая исключит подобные ошибки.

    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.

     
     
  • 6.51, Самокатофил (?), 15:12, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > Вродебы раст позиционируется как штука которая исключит подобные ошибки.
    > 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

    Как видишь, просто, без рук и ансейфа, как там ниже анон возмущается.

     
     
  • 7.58, Аноним (58), 15:31, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    > 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 },




     
  • 4.26, Alexey (??), 21:26, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Дык давайте тогда с C++ и C сравним. Вот где безопасность должна быть. Все-таки 40 лет разработки.
     
     
  • 5.28, Самокатофил (?), 21:38, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Но ведь "базовый синтаксис раст", май эс. ;)

    Сравнивать с цэ? Пожалуйста. С цэпэпэ - пожалуйста. С цэ/цэпэпэ - вам не кажется что это неадекватно? :-D

    Ну и положа руку на сердце, не думаете что тех CVE как-то слишком уж многовато для такого малоиспользуемого и маргинального языка? Ну, в сравнении с сишкой из 70х, и цэпэпэ, у которых петабайты исходного кода. Ммм?

     
  • 4.78, фывфывфыв (?), 13:56, 10/02/2022 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Внезапно, да, помог. Хочешь писать безопасно? Лови небольшие оверхеды и используй unsafe. Хочешь быстро? Следи за своим кодом сам. Что не так?
     
  • 3.24, Аноним (24), 21:19, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > И ответ - нет.

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

     
  • 3.41, Crazy Alex (ok), 11:33, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Если для практики, а не меряться "кто круче" - то вообще тривиально. Банальная проверка на отсутствие сырых указателей как членов класса и создания умных указателей из сырых (а не с помощью make_unique()/make_shared()) и арифметики с указателями вне begin() и  end() вылечит 99% проблем. Остаётся ещё всякий bounds checking по вычисленным индексам - но это в прицнипе в компайл-тайме не ловится, а в рантайме адски дорого.

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

    Другими словами - пишете код в рекомендованном современном плюсовом стиле, а не так, как привыкли до 11-го года - и нет проблем.

     
  • 2.25, ЛОЛВАТ (?), 21:26, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    в раст все работает из коробки
    раст даже пишет код за тебя
    неважно как и какой код написал раст программа будет работать так как ты задумал в голове. это не магия это раст.
     
     
  • 3.27, Alexey (??), 21:30, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, по сути язык заставляет писать код, который проходит его внутренний линтер (в его случае линтер следить за владением объектов). Так что априори код безопаснее, чем C++, где компилится даже откровенно бредовый код, который должен просто быть синтаксически верным. Т.е. можете просто написать код, который в бесконечном цикле выделяет через new память и не освобождает. И вам для этого даже не надо писать хаки, фича доступна из коробки.
     
     
  • 4.35, Аноним (35), 04:51, 09/02/2022 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 4.39, Аноним (38), 08:40, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Да что-то как-то не особо то и следит CVE-2021-45719 An issue was discovered i... большой текст свёрнут, показать
     
     
  • 5.44, Аноним (-), 12:50, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    >>который проходит его внутренний линтер (в его случае линтер следить за владением объектов).
    > Да что-то как-то не особо то и следит.
    > 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/426056c0924291367c9cee1


    +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,



    Какой громкий пук ...

     
     
  • 6.45, Аноним (38), 13:19, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Получается без unsafe ничего на Rust кроме Hello World не написать.
     
     
  • 7.50, Аноним (50), 15:05, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Получается без unsafe ничего на Rust кроме Hello World не написать.

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

     
     
  • 8.52, Самокатофил (?), 15:14, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    А что скажешь на это https github com jeromefroe lru-rs issues 120 Тоже си на... текст свёрнут, показать
     
     
  • 9.55, Аноним (55), 15:20, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какой чудный раст ... текст свёрнут, показать
     
  • 9.56, Аноним (58), 15:25, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    https github com jeromefroe lru-rs commit 3c6fdf07a4ab58f6a30bfdc68342fb6aa642... текст свёрнут, показать
     
  • 8.54, Аноним (55), 15:17, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что, раст ни для чего не подходит, кроме как написания обёрток вокруг Си ... текст свёрнут, показать
     
     
  • 9.57, Аноним (58), 15:28, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Кончай уже газифицировать лужи ... текст свёрнут, показать
     
  • 9.67, Самокатофил (?), 17:27, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Там выше пример, как и без оберток вокруг си можно в расте плодить уязвимости ... текст свёрнут, показать
     
  • 4.42, Crazy Alex (ok), 11:35, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ...а потом оказывается, что вы пишете программу для тестирования работы OOM киллера.

    Что характерно - написать бесконечный цикл, тыпо выделяющий память (ну в виде создания объектов, например) можно вообюще на любом языке.

     
  • 2.31, Аноним (31), 23:55, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    В компилятор встроен - одна половина MIR, вторая половина в официальном крейте Miri https://github.com/rust-lang/miri#bugs-found-by-miri
     
     
  • 3.32, Аноним (31), 00:00, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Есть еще tsan https://github.com/tokio-rs/loom
     
  • 2.81, Redanec (?), 23:41, 11/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Miri
     

  • 1.3, Аноним (3), 16:49, 08/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пользуются ли ей разработчики KDE?
     
  • 1.9, Анонн (?), 18:13, 08/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Отличный и крайне недооцененный проект. Жалко что им так мало пользуются.
     
     
  • 2.13, Аноним (15), 19:30, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    много кто пользуется
     
  • 2.19, Alexey (??), 20:07, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Сильно много ложных срабатываний.
     
  • 2.20, Самокатофил (?), 20:14, 08/02/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Отличный. Когда-то даже удивился, увидев его враппер в исходниках wireshark'a. Инструмент оцененный теми, кому надо. Вот бы еще разраб сделал нормальный ман, вместо этого генерируемого убожества... просто же, ну, или, если удобно так -- добавлять в дист сгенеренный ман, как принято у аристократии...
     

  • 1.30, Аноним (30), 23:44, 08/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >> Добавлена поддержка представлений (view) контейнеров - в тег библиотеки добавлен атрибут view, указывающий, что класс является представлением. Код анализа времени жизни обновлён для использования данного атрибута при поиске "висячих" контейнеров;

    Когда я изучал С++ там не было ни вью, ни контейнеров. Тем более висячих.

     
     
  • 2.33, Аноним (33), 02:20, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Когда я изучал C++ не было ... так что и ну его нафиг
     
     
  • 3.48, Аноним (48), 13:57, 09/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Когда Я изучал, С++ еще не было..
     
     
  • 4.74, . (?), 06:49, 10/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    я ждал что ктото это напишет. такие вы пупсики
     

  • 1.34, . (?), 03:46, 09/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    странные ощущения оставляет. как будто зря каждый раз жру кактус чтобы его настроить, а выдача как от модных варнингов гцц. (про си)
     
  • 1.37, Аноним (37), 07:12, 09/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Описание к третьей ссылке поправьте. Во-первых, MIRSA - это не стиль оформления кода. Во-вторых, в cppcheck нет проверок стилей оформления кода.
     
     
  • 2.76, Аноним (76), 09:39, 10/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Им посрать.
     
  • 2.77, Совершенно другой аноним (?), 11:28, 10/02/2022 [^] [^^] [^^^] [ответить]  
  • +/
    Подскажите пожалуйста, как это лучше назвать? Стиль кодирования? Правила кодирования?
     
     
  • 3.80, Аноним (-), 09:11, 11/02/2022 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Правописание.
     

  • 1.43, InuYasha (??), 11:38, 09/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то подсказывает мне, что donate-cpu.py имеет в зависимостях donate-bandwidth.py...
     
  • 1.75, Аноним (76), 09:38, 10/02/2022 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Не надо. Далее стандартные средства студии находят больше, чем это.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру