Andrey Karpov Andrey2008

Продолжение про Awesome-hpp. Проверка коллекции header-only C++ библиотек (awesome-hpp).

Continue. Checking a Header-Only C++ Library Collection (awesome-hpp).

И я как раз сегодня опубликовал статью на тему проверки сторонних библиотек :)
Проверка коллекции header-only C++ библиотек (awesome-hpp).

Проверили :). Amnesia: The Dark Descent или как забыть поправить копипасту.

Спасибо за этот анекдот. Он послужил основой дня новой статьи :).

По мотивам обсуждений написал новую статью. Приглашаю познакомиться: Продолжение: обидно за мнения про статические анализаторы кода.

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

Поздравляю, Вы запутали анализатор. А заодно и всех, кто будет сопровождать этот код. :)

Вопрос расплывчатый. Если в целом, то ответ: да, учитываются.

Разное будет… Зависит от volatile. Зависит от, что такое такое bar() и что такое p. Если p это член класса, а bar() константная функция класса, то значит p меняться не может и это одна ситуация. А если это не константная функция, то эта другая ситуация… Смотря что такое ENTER_CRITICAL_SECTION… Если хочется получить ответы, как и что будет в конкретном случае, предлагаю поиграться с PVS-Studio online.

Если же вопрос: Можно запутать PVS-Studio? Ответ: Да, можно. :)

Понятно. Спасибо. В PVS-Studio есть аналогичные подсказки.

Меж строк читается предположение, что статические анализаторы не знают про асинхронность :). А они кое-что вполне знают и учитывают :). И даже имеют некоторые специализированные диагностики (пример, пример).

Как я понимаю, это некий аналог [[noreturn]] функций? Анализатор PVS-Studio ориентируется на такие вещи. Аккуратно написанный код снижает количество ложных срабатываний. Например, диагностика V779 на это смотрит. И другие: пример.

void error_1();
[[noreturn]] void error_2();

void warning()
{
    int A[10];
    for (int i = 0; i < 20; i++)
    {
        if (i > 9)
            error_1();
        A[i] = 1; // есть предупреждение
    }
}

void ok()
{
    int A[10];
    for (int i = 0; i < 20; i++)
    {
        if (i > 9)
            error_2();
        A[i] = 1; // нет предупреждения
    }
}

Примечание общего плана. Мне не очень понятна страсть к рассмотрению в комментариях каких-то особенных случаев (асинхронность, DMA и так далее). На одно ложное срабатывание из-за такой причины, приходится 100 обыкновенных ошибок-опечаток. Может ли анализатор ошибаться? Да, может. Однако, на один хитрый особенный низкоуровневый if приходиться 5000 обыкновенных. Давайте получать пользу от их проверки :).

В большинстве случаев volatile переменные рассматриваются особенно и сделаны специальные исключения в диагностиках. Кое-что про асинхронность PVS-Studio тоже знает.

False positives are our enemies, but may still be your friends.

Спасибо :)

Continue. Nullable Reference will not protect you, and here is the proof.

Продолжение. Nullable Reference не защищают, и вот доказательства.

AI/ML давно такое делает

Ну, как сказать, делает… Использование машинного обучения в статическом анализе исходного кода программ.

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

Ну и да, не забывайте помимо поиска известных ляпов, проводить классический статический анализ для поиска дефектов безопасности (SAST). Наш анализатор PVS-Studio уже умеет для этого работать в режиме классификации предупреждений согласно CWE, CERT и скоро добавим OWASP.

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

Итак, в комментариях к этой статье люди писали, что там есть и другие места, которые по всей видимости являются ошибками. И что вообще код написан сложно и неаккуратно. Очень рад, что данная тема вызвала интерес. Поэтому в продолжение предлагаю публикацию «Почему важно проводить статический анализ открытых библиотек, которые вы добавляете в свой проект» :). habr.com/ru/company/pvs-studio/blog/520498

Такое пока нет. ;) Но, спасибо.

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

Да, так и есть :). Спасибо.

P.S. На эту тему: PVS-Studio — двигатель прогресса.

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

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

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

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

Feedback: Static code analysis of the PMDK.

Feedback: Static code analysis of the PMDK.

Не могу пройти мимо, и не вставить ссылку на статический анализатор PVS-Studio :). Возможно, кто-то пропустил новость, что теперь он доступен как плагин для IntelliJ IDEA!

О, а баг-то, продолжает жить :).

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

Почему?

Продолжение Azure DevOps тематики. PVS-Studio: Анализ pull request-ов в Azure DevOps при помощи self-hosted агентов.

Continue. PVS-Studio: analyzing pull requests in Azure DevOps using self-hosted agents.

Бесплатные варианты лицензирования PVS-Studio.

Всё правильно написали. Кстати и в целом задачи у компиляторов и анализаторов разные. Компилятор должен работать как можно быстрее. Анализатор, так как запускается реже (другие сценарии использования), может (и вынужден) работать медленнее и потреблять больше памяти.

А PVS-Studio пробовали? :)