Евгений Рыжков
ООО "СиПроВер"

 Ноябрь 2009

Аннотация
Введение
Подготовка к использованию
Описание функции "Mark as False Alarm"
Принцип постоянного использования PVS-Studio в процессе разработки программного проекта
Пояснения по реализации
Другие способы фильтрации сообщений в анализаторе PVS-Studio
Возможные проблемы
Заключение
Библиографический список


Аннотация

В статье приведены описание и пример использования новой функции PVS-Studio 3.40 "Mark as False Alarm" ("Пометить как ложное срабатывание"). Эта функция позволяет разметить те диагностические сообщения анализатора PVS-Studio, которые являются "ложными срабатываниями", чтобы не видеть эти сообщения при следующем запуске анализатора. 

Введение

Любой анализатор кода всегда выдает помимо полезных сообщений об ошибках еще множество так называемых "ложных срабатываний". Это ситуации, когда программисту совершенно очевидно, что в коде нет ошибки, а анализатору это совсем не очевидно. Причина этого понятна - программист владеет большей информацией о проекте, о допустимых входных параметрах, о способах использования этого кода. Программе, не обладающей этими знаниями и интеллектом, которой и является любой анализатор кода, подобный уровень точности недостижим. Поэтому анализатор и выдает много казалось бы совершенно глупых сообщений.
Вообще в мире есть два подхода, как относиться к ситуации, когда помимо полезных сведений (сообщений о реальных ошибках) инструмент выдает еще много "шума". 
Первый подход - в качестве результата выдавать сообщениях только о тех ошибках, когда это стопроцентная ошибка. В этом случае есть риск потерять те ошибки, которые явлются проблемными только с невысокой вероятностью. То есть ложных срабатываний будет очень мало, но есть опасность пропустить реальные ошибки.
Второй подход - выдавать все сообщения обо всех ошибках, которые могут (но не обязательно) являться реальными проблемами. В этом случае количество ложных срабатываний будет намного больше, но зато и потерь реальных ошибок практически не будет.
В любых анализаторах кода (не только в PVS-Studio, но и в PVS-Studio в том числе) разумно применять второй подход. Этому есть крайне простое объяснение. Любой инструмент для выявления программистских ошибок используется тогда, когда найти проблемы без него невозможно. Соответственно часто это вообще единственный способ найти дефекты, скрытые в многомегабайтном десятилетнем коде. И если какой-то инструмент не выдаст сообщение об ошибке, посчитав эту ошибку "недостаточно убедительной", то ценность такого инструмента сомнительна.
Столь пространное введение является попыткой объяснить, почему анализатор PVS-Studio выдает довольно много сообщений об ошибках, которые на самом деле ошибками не являются.
Анализатор кода - это инструмент, который подсказывает те места в коде программы, которые программист должен посмотреть вручную и уже программист определит, есть ли там реальные ошибки или нет. Если анализатор кода выдает много сообщений о потенциальных проблемах, то программист должен просмотреть, конечно же, много мест в коде. Однако если анализатор выдает мало сообщений (и только о гарантированных ошибках), то программист просто не увидит строк кода с реальными проблемами.
Итак, мы выяснили, что анализатор не может не выдавать много диагностических сообщений. Однако как же тогда постоянно работать с таким количеством сообщений? С помощью новой функции PVS-Studio 3.40 "Mark as False Alarm" работа с большим количеством сообщений стала еще более удобной. Описанию этой функции и посвящена настоящая статья.

Подготовка к использованию

В PVS-Studio 3.40 появилась возможность пометить сообщение об ошибке, полученное от PVS-Studio, как ложное срабатывание. Это можно делать либо вручную, либо с помощью команды меню или панели инструментов.
Покажем, как пользоваться этой функцией на демонстрационном примере PortSample, который идет в дистрибутиве вместе с PVS-Studio.
Сначала необходимо установить PortSample (рисунок 1).

Рисунок 1 - Установка примера PortSample

Затем открыть PortSample (рисунок 2).

Рисунок 2 - Открытие примера PortSample

Открыв проект, запустим анализ решения с помощью команды "Check Solution" (рисунок 3).

Рисунок 3 - Запуск анализа

По завершении анализа будет выведен список сообщений об обнаруженных проблемах (рисунок 4).

Рисунок 4 - Список проблем, обнаруженных с помощью PVS-Studio

Этот список сообщений нужно просмотреть и проанализировать.

Описание функции "Mark as False Alarm"

Перейдем на самое первое сообщение об ошибке:Этому сообщению (и этой строке) соответствует код:Проблема в переменных, которые объявлены выше и имеют тип unsigned:Это ошибка, и правильно было бы использовать тип size_t вместо unsigned. Однако если в вашем случае эта ошибка не является важной, то вы можете "отключить" выдачу конкретно этого типа сообщения (V101) в конкретно этой строке (34) этого файла (v1xx.cpp). Для этого нужно выделить в окне Error List сообщение об ошибке и выбрать команду "Mark Selected Errors as False Alarm" или в меню PVS-Studio, или на панели инструментов (рисунок 5).

Рисунок 5 - Команда "Mark Selected Errors as False Alarm"

После этого в код автоматически добавится комментарий " //-V101":Этот комментарий сообщает анализатору кода, что в следующий раз при анализе проекта выдавать сообщение об этой ошибке в этой строке не надо.
Комментарий можно добавить и вручную без использования команды "Mark Selected Errors as False Alarm", но важно полностью соблюдать формат записи: две косые черты, минус (без пробела), код ошибки.
После пометки сообщения как ложное срабатывание можно выбрать команду "Refresh Error List to Hide Errors Marked as False Alarm" (рисунок 6) для того, чтобы обновить список сообщений об ошибках и скрыть ненужное сообщение. В окне Error List станет на одно сообщение меньше.

Рисунок 6 - Команда "Refresh Error List to Hide Errors Marked as False Alarm"

Удалить комментарий можно с помощью команды "Remove False Alarm Mark from Selected Errors", предварительно выделив сообщение об ошибке в Error List. Также комментарий можно удалить и вручную.

Рисунок 7 - Команда "Remove False Alarm Mark from Selected Errors"

Итак, мы пометили одну ошибку как "ложное срабатывание". До разметки в окне Error List было (в зависимости от настроек) 35 сообщений. Перезапустим анализ; мы получим 34 сообщения. При этом в списке сообщений уже нет того сообщения, которое было помечено как "ложное срабатывание".
Если необходимо в окне Error List получить все-таки все сообщения, включая и помеченные как False Alarm, то можно выбрать команду "Show Errors Marked as False Alarm in Error List" (рисунок 8). 

Рисунок 8 - Команда "Show Errors Marked as False Alarm in Error List"

Можно пометить сразу несколько сообщений. Для этого нужно выбрать их в окне Error List (рисунок 9).

Рисунок 9 - Выбор нескольких сообщений для разметки в окне Error List

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

Принцип постоянного использования PVS-Studio в процессе разработки программного проекта

Появление в PVS-Studio возможности "Mark as False Alarm" значительно расширяет потенциал внедрения анализатора кода в процесс разработки программного обеспечения. Теперь анализатор удобно запускать не время от времени, а, например, ежедневно. 
Принцип подобной работы с анализатором кода состоит из двух этапов: внедрение и постоянное использование. Предположим, есть большой программный проект из нескольких миллионов строк кода. Постоянно в проекте участвует двадцать программистов. Пусть необходимо перенести этот проект на 64-битную систему. (Использование анализатора параллельного кода из PVS-Studio совершенно аналогично, но для простоты изложения будем говорить о разработке 64-битной версии.)
Мы предлагаем такой вариант использования нашего инструмента.
Сначала команда из пяти разработчиков создает базовую компилирующуюся конфигурацию 64-битной версии проекта, исправляет основные ошибки и предупреждения компилятора. После чего, разделив проект между собой по частям, запускает анализатор PVS-Studio. В течение некоторого времени (дней/недель/месяцев) в зависимости от объема исходного кода команда из пяти разработчиков либо исправляет обнаруженные проблемы (сообщения от анализатора), либо помечает их как False Alarm в коде. В результате после завершения работы команды над миграцией кода PVS-Studio не будет выдавать ни одного нового сообщения, так как все ошибки будут либо исправлены, либо помечены как ложные срабатывания.
После этого к работе над проектом (и дальнейшим его развитием) приступают остальные 15 человек. Они, разрабатывая новый код, могут запускать ежедневно анализатор и исправлять возможные ошибки только в новом коде. При этом старые уже обработанные сообщения анализатора они видеть не будут.
Такой подход позволяет не только выполнить миграцию приложения на 64-битную платформу, но и быть уверенным в отсутствии 64-битных проблем в новом только что разработанном коде.
Естественно, применение PVS-Studio для поиска ошибок параллельного программирования точно так же возможно в таком же режиме. Первый этап по анализу и разметке ложных сообщений выполняет небольшой состав разработчиков. После чего уже PVS-Studio может использовать вся команда, обращая внимание на ошибки только в своем новом коде.

Пояснения по реализации

Этот раздел посвящен обсуждению принципов реализации. Раздел могут пропустить те читатели, которых не беспокоит вопрос: "А почему же вы используете комментарии, а не стандартные #pragma-директивы?".
Обычно в компиляторах для подавления отдельных сообщений об ошибках используют #pragma-директивы. Приведем пример кода: Компилятор выдает сообщение:Это сообщение можно подавить с помощью следующей конструкции:Точнее, чтобы подавить конкретно это сообщение, лучше оформить код так:Ничто не мешало реализовать подобный подход и в PVS-Studio, однако мы решили сделать по-другому. Мы в качестве разметки используем комментарии специального вида. Для той же строчки кода подавление сообщения PVS-Studio будет выглядеть так:Казалось бы, разница не велика, ведь мы могли бы расширить синтаксис однострочных #pragma-директив, чтобы не писать push/pop для каждой конструкции. Но этот вариант имеет существенный недостаток. Дело в том, что PVS-Studio может сообщать о проблемах в середине многострочных выражений, как, например, здесь:Для того чтобы подавить это сообщение при использовании комментария, достаточно написать:Если же в это выражение пришлось бы добавлять #pragma-директиву, то код выглядел бы значительно менее наглядно.
Итак, использование комментариев вместо #pragma-директив для маркировки файлов значительно более удобно.
Другой вопрос, который может возникнуть по реализации механизма разметки: "А зачем вообще трогать код? Нельзя ли хранить информацию о ложных срабатываниях в другом месте отдельно от кода?" 
Теоретически можно сделать отдельную базу, в которой хранить информацию примерно так: код ошибки, имя файла, номер строки. Однако этот подход очень плох. Ведь если добавить в начало размеченного файла несколько строк, то все размеченные сообщения сдвинутся, и база потеряет актуальность.
В случае же когда разметка хранится в исходном коде, то при любой модификации кода информация о строке с ошибкой не потеряется.

Другие способы фильтрации сообщений в анализаторе PVS-Studio

Помимо нового, описанного в этой статье способа фильтрации сообщений, кратко напомним про три других способа, существующих в анализаторе изначально.
Во-первых, можно отключить диагностику тех или иных ошибок по их коду. Это делается с помощью вкладки "Настройки: Detectable Errors". На вкладке обнаруживаемых ошибок можно указать номера ошибок, какие не надо показывать в отчете по анализу. Иногда бывает целесообразно убрать в отчете ошибки с определенными кодами. Например, если вы уверены, что ошибки, связанные с явным приведением типа (коды V201, V202, V203) вас не интересуют, то вы можете скрыть их показ.
Во-вторых, можно отключить анализ некоторых частей проекта (точнее некоторых папок проекта). Раздел "Настройки: Exclude From Analysis". На этой можно ввести информацию о библиотеках, включения (через директиву #include) из файлов которых анализировать не надо. Это может потребоваться для уменьшения количества лишних диагностических сообщений. Например, в проекте используется библиотека Boost. И хотя на какой-то код из этой библиотеки анализатор выдает диагностические сообщения, вы считаете, что эта библиотека является достаточно надежной и написана хорошо. Поэтому, возможно, не имеет смысла получать диагностические сообщения по поводу кода в этой библиотеке. В этом случае можно отключить анализ файлов из этой библиотеки, указав путь к ней на странице настроек.
В-третьих, можно подавлять отдельные сообщения по тексту. На вкладке "Настройки: Message Suppression" можно настроить фильтрацию ошибок по содержащемуся в них тексту, а не по коду. При необходимости можно скрыть из отчета сообщения о диагностированных ошибках, содержащих определенные слова или фразы. Например, если в отчете есть ошибки, в которых указаны названия функций printf и scanf, а вы считаете, что ошибок, связанных с ними, быть не может, то просто добавьте эти два слова с помощью редактора подавляемых сообщений.

Возможные проблемы

При использовании возможности "Mark as False Alarm" существуют несколько потенциальных проблем. Хотя они и не связаны с анализатором PVS-Studio напрямую, знать о них желательно.
Иногда анализатор кода "промахивается" с номером строки содержащей ошибку. Например, анализатор говорит, что ошибка в строке 57, а строка 57 - вообще пустая строка. При этом исходный код, который вызывает ошибку, находится строчкой выше, например, в строке 56.
Дело в том, что анализатор кода использует препроцессор из Visual C++ во время своей работы. И в препроцессоре есть некоторые ошибки. Так, например в Visual Studio 2005 (без Service Pack 1) есть проблема с многострочными макросами (#define). К счастью в Visual Studio 2005 Service Pack 1 и в Visual Studio 2008 этой проблемы нет. Подробнее об этом написано в нашем блоге (PVS-Studio выдает ошибку "Some diagnostic messages may contain incorrect line number for file ...")
Другая проблема препроцессора связана с многострочными #pragma-директивами определенного типа, из-за которых также сбивается нумерация строк. К сожалению, эта ошибка пока не исправлена ни в каких версиях Visual Studio. Подробнее смотрите в нашем блоге (PVS-Studio выдает ошибку "Some diagnostic messages may contain incorrect line number for file ..." (продолжение)).
Итак, к чему же может привести сбой нумерации строк в сообщениях от PVS-Studuio? Может случиться так, что автоматически расставленные разметки будут не в том месте, где должны быть. И тогда анализатор вновь выдаст эти же сообщения об ошибках, так как маркер не будет найден.
Решением проблемы является пометка сообщений, на которых заметен сбой, вручную.
Сразу же успокоим читателя, так как эти проблемы проявляются крайне редко. И когда происходит сбой нумерации строк в файле, PVS-Studio всегда сообщает об этом строкой "Some diagnostic messages may contain incorrect line number for file ...". Если такого сообщения нет, то и проблемы нет.
Повторим, это случается крайне редко на очень специфичных проектах.
Другая возможная проблема относится не к PVS-Studio, а вообще к процедуре работы с файлами исходного кода. Мы очень тщательно тестировали механизм разметки файлов и крайне внимательно проверяли код. Тем не менее, полностью застраховаться от сбоев при обработке файлов (особенно массовой) конечно же, нельзя. Речь не о проблемах в PVS-Studio. Просто теоретически, во время разметки файлов один из файлов может быть открыт во внешнем редакторе и там модифицирован. Результат совместной работы с файлом предсказать невозможно. PVS-Studio здесь вроде бы не причем, но пользователь может подумать, что виновата программа. 
Поэтому мы рекомендуем либо иметь копию исходных кодов, либо просто пользоваться системами контроля версий. Мы уверены, что читатель наверняка пользуется подобной системой. Но лучше предупредить еще раз.

Заключение

Анализатор PVS-Studio с появлением возможности "Mark as False Alarm" стал значительно более удобным в использовании. Надеемся, что теперь вы сможете внедрить его в постоянный процесс разработки. А это значит, что количество 64-битных и параллельных ошибок в ваших программах станет значительно меньше.

Библиографический список

1. Евгений Рыжков. Знакомство с анализатором кода PVS-Studio. http://www.viva64.com/art-4-1-1298120896.html
2. Евгений Рыжков. Учебное пособие по PVS-Studio. http://www.viva64.com/art-4-1-1796251700.html