Pull to refresh
52
Karma
0
Rating
Павел Еремеев @Paull

Технический директор

PVS-Studio 7.22: Visual Studio Code, Qt Creator, .NET 7

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

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

Технологии статического анализа кода PVS-Studio

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

Технологии статического анализа кода PVS-Studio

Спасибо, обязательно глянем.

Технологии статического анализа кода PVS-Studio

PVS-Studio поддерживает языки C, C++, Java и C#. Соответственно, из перечисленных пунктов, для поддерживаемых нами языков, часть из данных требований мы поддерживаем (например, классификации по OWASP и CWE), часть не поддерживаем (например, HIPAA и анализ бинарных файлов). У нас есть поиск потенциальных уязвимостей, но нет поиска НДВ.

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

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

Технологии статического анализа кода PVS-Studio

Рад, что вам понравилось!

По поводу сравнения с другими решениями - мы пробовали такой формат, уже достаточно давно, лет 6-7 назад, и пришли к выводу, что это, скорее, достаточно неблагодарное занятие, если мы занимаемся этим сами. К сожалению, у читателя всегда остаётся ощущение предвзятости. Сравнение анализаторов вообще достаточно сложная задача, т.к. оно затрагивает очень много факторов, и, в большлинстве случаев, результатом получается некое пересечение множеств - каждый анализатор умеет что-то своё, что не умеет другой.

Поэтому сравнивать, как мне кажется, имеет смысл по какой-то конкретной характерристике, а не в общем. Если вас интересует что-то такое конкретное именно в плане сравнения с Solar appScreener - если вы её уточните, я попробую что-нибудь найти для вас.

Технологии статического анализа кода PVS-Studio

Смотрите - именно типы ошибок, если мы говорим об анализе общего назначения (т.к. например диагностики по стандарту MISRA С точно никогда не пересекуться с другими языками), между данными 3-мя языками (C++, C#, Java) пересекаются достаточно сильно - речь идёт о десятках процентов таких общих ошибок. Это, однако, не означает, что в одном из анализаторов мы получаем "бесплатные" ошибки, если они уже есть в другом - по крайней мере, в случае с PVS-Studio, нам всё-равно приходится реализовывать такие общие диагностики в каждом анализаторе отдельно.

Конечно, мы переиспользуем уже имеющуюся экспертизу по такой диагностике, что сильно помогает, но это всё-таки не "бесплатно". Теоретически, такай подхват общих диагностик анализаторами для разных языков возможен (и мы знаем, что такие анализаторы есть) - обычно это делается на уровне некоего общего промежуточного представления, в котором работают сразу несколько анализаторов, однако в случае с PVS-Studio исторически сложилось так, что каждый анализатор уникален.

Лучшие срабатывания статического анализатора

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

Лучшие срабатывания статического анализатора

На самом деле, сам статический анализ - достаточно широкая область, помимо традиционного "поиска ошибок в коде". Это и всяческий рефакторинг и кодстайлы, это и защищённость (SAST) и безопасность (MISRA, AUTOSAR) кода, это и анализ состава ПО (SCA), где методики статического анализа также используются - статический анализ это инструмент, которым очень много задач можно решать во множестве областей, и мы последние годы многое из перечисленного выше стали затрагивать в той или иной мере.

Оптимизация .NET приложения: как простые правки позволили ускорить PVS-Studio и уменьшить потребление памяти на 70%

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

Алгоритм наш собственный.

Оптимизация .NET приложения: как простые правки позволили ускорить PVS-Studio и уменьшить потребление памяти на 70%

Действительно, гонять проверку и заниматься оптимизацией на клиентском коде было бы проще всего, однако возникают проблемы юридического плана — мало кто отдаст всю свою кодовую базу в стороннюю компанию, а уж сколько документов придётся для этого оформлять.

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

В «osu!» играй, про ошибки не забывай

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

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

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

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

В «osu!» играй, про ошибки не забывай

кажется, что вместо всего этого надо просто выдать один варнинг внутри updateResult

Анализатор внутри этого метода знает конечно, что оно всегда false, и если переменную с чем-то сравнивали бы, например, он бы на это ругнулся — но просто на return какого-то значения у нас диагностики нет.

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

Неочевидно, что стоит выдавать какие-то варнинги в точках вызова, это только шум.

Инкапсуляция, исполнение контрактов — можно найти тысячу причин, почему что-то не стоит делать. А можно просто уметь это делать и находить сотни подобных интересных срабатываний, как это делает PVS-Studio )

Nullable Reference типы в C# 8.0 и статический анализ

Да, безусловно, ложно-положительные срабатывания неизбежны при работе статического анализатора, однако такой огромный процент скорее свидетельствует о том, что анализатор нужно дополнительно настроить перед использованием — отключить какие-то диагностики, добавить исключения на определённые файлы, unit тесты и т.п.

Nullable Reference типы в C# 8.0 и статический анализ

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

Проверяем исходный код Roslyn

В конце этой недели у нас запланирован релиз с поддержкой VS2019\C# 8.0. Конкретно по поддержке nullable reference и всего специфичного для них синтаксиса — анализатор будет понимать, что это такое, и что оно значит, но на работу каких-то диагностик nullable reference никакого влияния оказывать пока не будет, по крайней мере в этом релизе.

Например, если вы где-то глубоко в своём коде в не-nullable переменную всё-таки запишите null (что сделать можно с помощью оператора '!', например), и затем без проверки будете эту переменную использовать, анализатор это увидит и ругнётся. Возможно в дальнейшем наше поведение с не-nullable refernce типами будет меняться, посмотрим на отзывы пользователей, будем расширять нашу тестовую базу по мере того, как новый синтаксис будет приниматься на вооружение разработчиками.

История о том, как мы иконку PVS-Studio меняли

Предпоследней не хватает индивидуальности — вбейте в гугл картинки triangle logo, и вы увидите точно такую же )

Внедряйте статический анализ в процесс, а не ищите с его помощью баги

Потому что он не только находит но ещё и обновляет чтобы быстрее анализировалось, понятно что это для скорости. Но, если бы была настроечка включающая одну базу на sln/CmakeLists то было бы имхо попроще.

У нас можно добавлять suppress файл как на уровень sln (в случае Visual Studio проектов), так и при использовании прямой CMake интеграции (с нашим CMake модулем) Suppress файлы, однако, работают на уровне исходных файлов, поэтому если кусок кода переедет из одного файла в другой, то diff всё равно вылезет.

Также, если sln генерится CMake'ом, то добавлять в него suppress может быть неудобно — в таком случае можно в каждый ваш проект добавить общий suppress файл (т.е. все проекты будут ссылаться на один файл), а чтобы не модифицировать каждый проект по-отдельности, suppress файлы можно добавлять в проекты через общие MSBuild props'ы.

PVS-Studio 7.00

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

Существует ряд способов учитывать такие изменения, и показывать именно новые срабатывания анализатора. Например, можно использовать предоставляемые PVS-Studio различные (в зависимости от сборочной системы и платформы) способы инкрементального анализа, анализирую, в т.ч. и на коммитах, только модифицированные файлы. Можно видеть новые ошибки, которых не было в предыдущих отчётах, использую механизм подавления срабатываний (мой коллега в комментарии выше давал ссылку на его описание). Наконец, quality-control системы наподобие SonarQube (для которого у нас есть плагин), обычно предоставляют схожую функциональность. В конечном счёте, всё зависит от конкретного сценария использования анализатора.

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

PVS-Studio 7.00

Ну во первых, наш продукт нельзя назвать чисто «32-битным» или «64-битным» — если говорить конкретно про Windows дистрибутив, то в него входит много разных утилит, некоторые из них (были) в том-числе 32-битными. Постепенно 32-битных утилит становится меньше, например наш C++ анализатор присутствовал в дистрибутиве как в виде 32-битной, так и 64-битной версий (сейчас от 32-битной версии мы отказались).

Во вторых, в папку Program Files (x86) он ставится, т.к. сам наш Windows инсталятор является 32-битным — можно сказать, что так исторически сложилось. В более старых версиях PVS-Studio, когда мы поддерживали старые IDE, такие как, например, Visual Studio 2008, возможно (я точно не ручаюсь, т.к. уже не помню), установка плагинов к таким IDE накладывала ограничения на создание чисто-64битного установщика. Также, PVS-Studio можно было установить и на 32-битную версию Windows (как я писал выше, сейчас это уже не актуально).

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

Короткая заметочка про PVS Studio в CI (и чего не хватает)

Но для того, чтобы это всё работало, необходима поддержка коротких путей как минимум на том диске, где ведётся анализ. Для этого в реестре по пути HKLM\SYSTEM\CurrentControlSet\Control\FileSystem необходимо установить параметр NtfsDisable8dot3NameCreation (DWORD) в значение, разрешающее сохранение коротких имён файлов. Подробнее — в MSDN.
Запрет по умолчанию на короткие имена нужно для увеличения скорости работы NTFS.
Можно либо поставить значение 0 и не заморачиваться, либо 3, если задачи CI выполняются в профиле пользователя на системном разделе или где-то в другом месте на системном разделе, либо в 2 и выполнить команду fsutil 8dot3name set Z: 0 (свой диск вместо Z:), где будет развёрнуто рабочее пространство CI (к RAM-дискам тоже относится, к слову).


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

Information

Rating
Does not participate
Location
Тула, Тульская обл., Россия
Works in
Date of birth
Registered
Activity