Время от времени мы рассказываем о своих внутренних исследованиях и разработках, которые происходят в команде разработчиков статического анализатора кода PVS-Studio для C/C++. Сегодняшняя история об очередной новинке, которую мы готовим в рамках нашего продукта.
Тем, кто следит за нашим проектом (а тем более пользуется им) известно, что наш анализатор изначально был плагином только для Visual Studio. Затем стало возможно пользоваться им как консольным приложением, встраиваемым в Makefile (спросите меня как, если не знаете). Потом, в начале этого года у нас появилась интеграция в C++Builder. Кстати у нас пока довольно мало пользователей под C++Builder, и мы не совсем понимаем почему. И вот недавно мы задумались над так называемым standalone приложением.
Вообще как для пользователя выглядит идеальный статический анализатор кода (в вакууме или нет)? Мне кажется, на основе моего опыта работы в этой области, идеальный анализатор должен выглядеть так. Пользователь скачивает утилиту, запускает ее, указывает папку с кодом и нажимает большую зеленую кнопку: «Найти все ошибки!». Никакой настройки, никакой «интеграции в проект». Ведь пользователю это не нужно? Да, не нужно. Но нужно анализатору кода, к сожалению. Как минимум, нужна информация по #include и #define, если мы говорим о C++. Она нужна для того, чтобы выполнить препроцессирование кода.
И тут мы приходим к необходимости выбора одного из вариантов:
- Либо инструмент должен сам извлекать эту информацию из файла проекта (как делают наши плагины для Visual C++ и C++Builder).
- Либо инструмент может получать эту информацию, если она ему будет передана в Makefile (как работает наша версия для командной строки).
- Либо инструмент заставляет пользователя мучительно вбивать все папки для #include и параметры #define, что почти невозможно, т.к. пользователю это сделать чрезвычайно сложно.
- Либо… придумать какой-то еще вариант.
Мы пошли по четвертому пути и решили попробовать так. А что если в качестве исходной информации анализатор будет получать не обычные исходники в виде .cpp-файлов, а уже препроцессированные файлы. Т.е. файлы, которые обработаны препроцессором. Это нас избавит от необходимости вызывать препроцессор, а соответственно знать эти #include и #define.
Конечно, это немного не совпадает с описанным выше идеальным вариантом анализатора. Но с другой стороны, это позволяет использовать PVS-Studio для практически любого С/С++ проекта, в какой бы среде разработки вы его не вели.
Итак, разрабатываемый в секретных лабораториях нашей команды инструмент выглядит примерно так:
Рисунок 1 – Диалог запуска проверки препроцессированных файлов.
Во-первых, мы указываем папку, где находится препроцессированные .i-файлы. Их и будет анализировать наш инструмент.
Во-вторых, мы указываем папку с исходниками. Это нужно для того, чтобы ошибки выявлять более точно. Кроме того, всегда лучше делать (в дальнейшем) навигацию по пользовательским .cpp-файлам, а не по не совсем понятным человеку .i-файлам.
В-третьих, мы указываем папку, в которой находятся системные include-файлы. Самые-самые базовые, вроде <string> или <stream>. Для чего? Чтобы анализатор знал, что вот здесь лежат те файлы, на которые выдавать диагностические сообщения не надо.
Итак, мы можем «скормить» препроцессированные файлы этой программе, и затем уже на них запускать анализатор. Именно таким образом мы и проверяем в настоящее время проект Boost. Кстати скоро будет отчет о проверке Boost – подпишитесь на наш блог, чтобы не пропустить. После проверки файлов мы получаем список диагностических сообщений вот в таком виде:
Рисунок 2 – Список диагностических сообщений после проверки i-файлов.
Обращаю внимание читателей на то, что это не Visual Studio или RAD Studio. Это отдельная утилита, которая повторяет полностью (точнее использует) окно PVS-Studio. В ней есть и встроенный редактор кода (Scintilla из Notepad++), который позволяет работать с ошибкам достаточно полноценно:
Рисунок 3 – Полноценный редактор кода.
Естественно этот пост не тянет на полноценное описание нашей новой секретной утилиты. Однако на несколько вопросов я уже могу ответить.
Кому НЕ нужна эта утилита? Тем, кто спокойно может проверить свой проект в PVS-Studio с помощью интеграции в Visual Studio и C++Builder. Кому НУЖНА эта утилита? Тем, кто хочет проверять свой код с помощью PVS-Studio и использует другие среды разработки и/или проектные файлы, в которые сложно встроить нашу утилиту командной строки.
Какой бы вы хотели видеть такую утилиту? Удобен ли вам режим проверки по готовым препроцессированным файлам? Чего не хватает в такой утилите? Выпускать ли нам ее или забросить дальнейшие разработки этой утилиты, так как всех устраивает наша интеграция в среды от Microsoft/Embarcadero?
P.S. Кстати мы обновили дизайн нашей базы ошибок, обнаруженных в open source проектах.
Автор: EvgeniyRyzhkov
