Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Мифы о статическом анализе. Миф четвёрт…

Мифы о статическом анализе. Миф четвёртый – программисты хотят добавлять свои правила в статический анализатор

04 Ноя 2011

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

Миф четвертый: "Статический анализатор должен иметь возможность добавлять пользовательские правила. Программисты хотят добавлять свои собственные правила."

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

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

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

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

Программисты действительно хотят искать некоторые паттерны/ошибки в своём коде. Им это действительно нужно. Например, человеку нужно найти вся явные приведения от типа int к float. Эту задачу нельзя решить, используя такие инструменты, как grep. Ведь в конструкции вида "float(P->FOO())" неизвестно какой тип вернет функция FOO(). В этот момент программист и приходит к выводу, что он может реализовать поиск таких конструкций, добавив свою проверку в статическом анализаторе.

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

Именно поэтому и я, и Дмитрий не поддерживаем идеи предоставлять пользователю API для работы с анализатором. Это крайне сложная задача с точки зрения разработки. И при этом от неё человек вряд ли будет использовать более 1%. Нерационально. Разработчику проще и дешевле реализовывать пожелания пользователей, чем создавать сложный API для модулей расширения или создавать специальный язык описания правил.

Читатель заметит: "тогда откройте в API только 1% от функциональности и все будут довольны". Да, всё правильно. Но смотрите, как сместился акцент. От разработки своих правил мы пришли к тому, что на самом деле достаточен инструмент, схожий с grep, но обладающий некоторой дополнительной информацией о коде программы.

Пока такого инструмента нет. Если вы хотите решить какую-то задачу, то можете написать мне, и мы постараемся реализовать её в анализаторе PVS-Studio. Например, недавно мы как раз реализовывали несколько пожеланий по поиску явных приведений типов: V2003, V2004, V2005. Воплощать в жизнь такие пожелания нам намного проще, чем создавать и поддерживать открытый интерфейс. Проще это и самим пользователям.

Кстати, возможно такой инструмент со временем появится в рамках Intel C++. Дмитрий Петунин говорил, что они обсуждали возможность создания grep-подобного инструмента, обладающего знаниями о структуре кода и типах переменных. Но это обсуждалось абстрактно. Я не знаю, планируется в действительности создать такое или нет.

Популярные статьи по теме
Эволюция PVS-Studio: анализ потока данных для связанных переменных

Дата: 28 Апр 2022

Автор: Никита Липилин

Связанные переменные – одна из главных проблем статического анализа. Данная статья посвящена разбору этой темы и рассказу о том, как разработчики PVS-Studio сражаются с ложными срабатываниями, появив…
Место SAST в Secure SDLC: 3 причины внедрения в DevSecOps-пайплайн

Дата: 19 Апр 2022

Автор: Сергей Васильев

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

Дата: 11 Янв 2022

Автор: Андрей Карпов, Павел Еремеев

PVS-Studio предоставляет статические анализаторы для языков C, C++, C# и Java на платформах Windows, Linux и macOS. Несмотря на некоторые различия, накладываемые особенностями отдельных языков, в цел…
Ускоряем сборку и анализ при помощи Incredibuild

Дата: 17 Май 2021

Автор: Максим Звягинцев

"Да сколько ты ещё будешь собирать?" – фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распар…
GTK: как выглядит первый запуск анализатора в цифрах

Дата: 04 Янв 2021

Автор: Святослав Размыслов

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

Комментарии (0)

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