05.02.2010
Ключ /Wp64 и ошибка с обработкой шаблонов
Занимаясь продвижением анализатора Viva64 (из состава PVS-Studio) мы часто комментируем ключ /Wp64 из Microsoft Visual C++.»
03.02.2010
Параллельные заметки №1 – технология OpenMP
В ближайшие несколько постов мы расскажем о практическом использовании многоядерных процессоров.»
29.01.2010
64-битные технологии - еще одно направление в современном программном обеспечении
В блогах и форумах довольно много говорится о многоядерных процессорах, как очевидном этапе развития компьютерных систем.»
2.02.2010 На нашем сайте стали доступны "Уроки разработки 64-битных приложений на языке Си/Си++".»
1.02.2010 Выпущена новая версия PVS-Studio 3.45!»
21.01.2010 Выпущена новая версия PVS-Studio 3.44!»
10.12.2009
Вопросы и ответы по PVS-Studio (PVS-Studio FAQ)
В документе собраны некоторые вопросы и ответы по анализатору кода PVS-Studio компании ООО "СиПроВер".»
09.12.2009
Вопросы и ответы по библиотеке VivaCore (VivaCore FAQ)
В документе собраны некоторые вопросы и ответы по библиотеке анализа Си/Си++ кода VivaCore компании ООО "СиПроВер".»
23.11.2009
PVS-Studio: использование функции "Mark as False Alarm"
В статье приведены описание и пример использования новой функции PVS-Studio 3.40 "Mark as False Alarm" ("Пометить как ложное срабатывание").»
Статья представляет собой учебное пособие (tutorial) по работе с анализатором кода PVS-Studio. Из нее вы узнаете об основных возможностях PVS-Studio, принципах работы с инструментом, а также об особенностях анализа кода некоторых типов приложений.
PVS-Studio - это статический анализатор кода, предназначенный для разработчиков современных ресурсоемких приложений на языках Си и Си++. Под современными мы понимаем 64-битные и/или параллельные приложения. Разработка таких программ имеет ряд трудностей, отличных от проблем традиционных программ. Ведь помимо обычных и всем известных ошибок вроде неинициализированных указателей, которые обнаруживаются любым компилятором, есть и новые типы проблем.

Речь идет об ошибках в программах, которые проявляются при миграции 32-битных приложений на 64-битные платформы. Или при распараллеливании кода для поддержки многопроцессорности или многоядерности. Разрабатывать такие приложения довольно сложно из-за недостатка инструментов, облегчающих создание 64-битных и параллельных программ. Анализатор PVS-Studio является именно таким инструментом!
Хотя пользовательский интерфейс анализатора кода PVS-Studio достаточно прост, тем не менее, для использования инструмента надо понимать принципы и технологию статического анализа кода, чтобы применение PVS-Studio было наиболее эффективно. Прочитав эту статью и разобрав рассматривающиеся в ней примеры, вы сможете использовать PVS-Studio в своей повседневной работе.
Статический анализатор кода PVS-Studio предназначен для разработчиков современных ресурсоемких приложений на языках Си и Си++. В настоящее время анализатор PVS-Studio содержит в себе два модуля:
С помощью этих двух модулей PVS-Studio позволяет обнаруживать в исходном коде программ на языках Си и Си++ следующие типы дефектов:
Анализатор PVS-Studio предназначен для работы на Windows-платформе. При этом он интегрируется в среду разработки Microsoft Visual Studio 2005/2008. Системные требования к анализатору совпадают с требованиями к Microsoft Visual Studio:
Получив установочный пакет PVS-Studio можно приступить к установке программы. К счастью это довольно простая процедура и никаких каверзных вопросов инсталлятор не задает.

Во время установки будет выполнена интеграция анализатора кода в Microsoft Visual Studio. В случае если на машине установлена какая-либо одна версия Microsoft Visual Studio (например, только 2005 или только 2008), то анализатор будет интегрирован лишь в нее. Если же несколько версий - то во все. Это определяется автоматически.
Также будет выполнена интеграция справочной системы PVS-Studio в MSDN. В PVS-Studio очень хорошая справочная система, которая содержит описания всех диагностических сообщений анализатора с примерами проблем в коде и способами их исправления. Кроме того в ней описаны все настройки, с помощью которых можно добиться лучшей диагностики от PVS-Studio.
После завершения установки PVS-Studio можно убедиться, что программа корректно установлена. Для этого надо запустить Microsoft Visual Studio и на стартовом экране появится логотип PVS-Studio (рисунок 3).

И хотя после этого сразу же можно приступать к работе, мы рекомендуем установить два дополнительных примера исходных кодов PortSample и ParallelSample (рисунок 4) из меню PVS-Studio\Issues Examples.

С помощью этих примеров можно на практике познакомиться с дефектами, которые бывают в современном программном обеспечении. PortSample содержит в себе примеры проблем, возникающие при миграции программного обеспечения с 32-битных систем на 64-битные. ParallelSample позволяет на практике увидеть, что бывает с параллельными программами содержащими "параллельные" ошибки.
Эти примеры (PortSample и ParallelSample) стоит установить, поскольку дальнейшее описание в статье будет опираться на них.
После установки примеров PortSample и ParallelSample можно начать знакомство с PVS-Studio. Откроем проект PortSample (vs2008) в Microsoft Visual Studio 2008, хотя тоже самое можно сделать и в Microsoft Visual Studio 2005 (рисунок 5).

Начинать знакомство с PVS-Studio стоит с одного из наших демонстрационных проектов по нескольким причинам:
Итак, откроем проект PortSample, выберем 64-битную конфигурацию x64 для проверки на наличие дефектов 64-битного кода, выберем с помощью панели команд PVS-Studio анализ 64-битных проблем - модуль Viva64 "64-bit issues (Viva64)" и запустим проверку всего решения командой "Check Solution". Все это показано на рисунке 6.

Конфигурация x64 выбрана специально. На проблемы 64-битного кода можно проверять только 64-битные конфигурации. Дело в том, что в 64-битной конфигурации настройки проекта отличаются от 32-битной. И делать проверку 64-битного кода в 32-битной конфигурации нельзя.
После запуска проверки на экране появится индикатор прогресса с кнопками Pause (приостановить анализ) и Stop (прервать анализ). Обнаруженные потенциально опасные конструкции во время анализа будут выводиться в окно найденных дефектов (рисунок 7).

Термин "потенциально опасная конструкция" означает, что данную конкретную строку кода анализатор посчитал дефектом. Является ли эта строка реальным дефектом в приложении или нет - определить может только программист, основываясь на своем знании приложения. Этот принцип работы с анализаторами кода очень важно правильно понимать. Вообще никакой инструмент не может полностью заменить программиста в задачи исправления ошибок в программах. Только программист, основываясь на своих знаниях, может это сделать. Но инструмент может и должен помочь программисту в этом. Поэтому задача анализатора кода - это сократить количество мест в программе, которое должен просмотреть и разобрать программист.
Но вернемся к анализатору PVS-Studio. Анализ всего кода завершен, и теперь можно приступить к просмотру сообщений. Кстати если у вас многоядерный процессор, то анализ завершится быстрее, так как будут использоваться все ядра.
Получив список диагностических сообщений от анализатора кода, можно приступать к его изучению. Перейдем к первой ошибке:
V101: Implicit assignment type conversion to memsize type. v1xx.cpp 34 |
Вот ее код:
size_t bufferSize = imageWidth * imageHeght *
bytePerPixel * maxFrameCountInBuffer;
|
Здесь проблема в том, что результирующий размер буффера (переменная bufferSize) имеет правильный размер size_t, а вот переменные, участвующие в выражении (imageWidth, imageHeight, bytePerPixel и maxFrameCountInBuffer), представлены типом int. В результате перемножение этих переменных дает значение также типа int. Это не страшно для значений меньше двух гигабайт, поскольку выполнится приведение типа. Но если в результате получится число больше двух гигабайт, то оно "обрежется" до двух гигабайт несмотря на то что переменная bufferSize имеет правильный тип. Для исправления ситуации необходимо изменить типы переменных, участвующих в выражении. Сделать это можно чуть выше по коду. Вместо:
unsigned imageWidth = 1000; unsigned imageHeght = 1000; unsigned bytePerPixel = 3; unsigned maxFrameCountInBuffer; |
напишем так:
size_t imageWidth = 1000; size_t imageHeght = 1000; size_t bytePerPixel = 3; size_t maxFrameCountInBuffer; |
Узнать об этом исправлении можно из справочной системы. Нажав F1 после перехода (мышкой или с помощью клавиши F4) к новой ошибке мы увидим открывшееся окно MSDN описанием ошибки:

После исправления используемых типов данных перезапустим анализ и увидим, что диагностических сообщений стало на одно меньше. Это значит, что проблема исправлена. Аналогичным образом надо пройтись по всем диагностическим сообщениям и исправить те места в коде, где возможны проблемы.
Разумеется, в больших реальных проектах диагностических сообщений будет не несколько десятков, а несколько сотен или даже может быть тысяч. И просмотр всех подобных сообщений может быть непростой задачей. Для того, чтобы облегчить ее, в анализаторе PVS-Studio имеются несколько механизмов. Первый - это фильтрация сообщений по коду ошибки. Второй - фильтрация по содержимому текста диагностического сообщения. Третий - фильтрация на основе путей к файлам. Рассмотрим примеры использования систем фильтрации.
Предположим, что вы уверены, что диагностические сообщения с кодом V112 (использование магических чисел) никогда не являются реальными ошибками в вашем приложении. Тогда можно отключить показ этих диагностических сообщений с помощью настроек анализатора кода:

После этого из списка сообщений пропадут все сообщения с кодом V112. Причем перезапускать анализ для этого не требуется. Если же включить обратно показ таких сообщений, то они вновь появятся в списке без перезапуска анализа.
Теперь рассмотрим другой вариант фильтрации на основе текста диагностических сообщений. Вернемся к примеру PortSample. Одной из ошибок в этом примере является доступ к массиву array с использованием индекса типа int:
V108: Incorrect index type for "array". Use memsize type instead. v1xx.cpp 183 |
Вот код:
volatile int index = 0; for (size_t i = 0; i != n; ++i) { array[index++] = 1; // проблема здесь if (array[i] != 1) throw CString("x64 portability issues"); } |
Конечно же, можно просто исправить тип переменной index с unsigned на size_t и проблема исчезнет. Но если подобного кода с доступом к переменной array много, а вы точно знаете, что в array не больше двух миллиардов элементов, то можно "попросить" анализатор кода не выдавать сообщения, в тексте которых используется слово array. Делается это с помощью настроек на вкладке MessageSuppression:

После этого все диагностические сообщения, текст которых содержит слово array, пропадут из списка без перезапуска анализатора кода. Вернуть их можно просто удалив слово array из фильтра.
Последним механизмом сокращения количества диагностических сообщений является фильтрация на основе путей к файлам проекта.
Предположим, в вашем проекте используется библиотека Boost. Анализатор будет, конечно же, сообщать и о потенциальных проблемах в этой библиотеке. Однако если вы уверены, что эти сообщения не стоит учитывать, то можно просто добавить путь к папке с Boost на вкладе ExcludeFromAnalysis:

После этого диагностические сообщения, относящиеся к файлам в этой папке, не будут показываться. Эта опция требует перезапуска анализатора кода.
В PVS-Studio имеется возможность "Mark as False Alarm". Благодаря ей возможно пометить в исходном коде те строки, в которых происходит ложное срабатывание анализатора кода. После разметки, анализатор более не будет выдавать диагностических сообщений на такой код. Это позволяет более удобно постоянно использовать анализатор в процессе разработки программного обеспечения для проверки нового кода.
Так в этом примере отключен вывод диагностического сообщения с кодом V104:
size_t n = 100; for (unsigned i = 0; i < n; //-V104 i++) { // ... } |
Подробно и обстоятельно эта возможность описана в статье "PVS-Studio: использование функции "Mark as False Alarm" ".
Есть также ряд других способов повлиять на выводимые диагностические сообщения путем настроек анализатора кода, но в рамках данного документа они не рассматриваются. Рекомендуем обратиться к документации по настройкам анализатора кода.
Когда вы просмотрите все сообщения, которые выдал анализатор кода, то вы найдете как реальные ошибки в программах, так и конструкции не являющиеся ошибочными. Дело в том, что анализатор не может на 100% точно определить все ошибки в программах без так называемых "ложных срабатываний". Только программист, зная и понимая программу, может определить есть в конкретном месте ошибка или нет. Анализатор кода же только существенно сокращает количество мест, которые необходимо просмотреть разработчику.
Таким образом добиваться исправления всех потенциальных проблем, на которые указывает анализатор кода, смысла, конечно же, нет.
Но стремиться исправить как можно большее количество кода стоит. Особенно это актуально, когда статический анализатор используется не однократно для верификации приложения, например, при его переносе на 64-битную систему, а регулярно с целью выявления вновь внесенных ошибок и неэффективных конструкций. В этом случае исправления потенциальных мест, которые на самом деле ошибками не являются, а также настройка анализатора на подавления определенных видов ошибок, позволит существенно сократить время при последующем использовании анализатора.
К началу | О нас | Контакты | Политика конфиденциальности | Соглашение об использовании
© 2008 - 2010, ООО "СиПроВер", 300027, Россия, Тула, а/я 1800, тел. +7 (4872) 38-59-95. Офис: Россия, Тула, Кутузова 100, офис 73.