to the top
close form
Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

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

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

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

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

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


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

>
>
Чем статический анализ отличается от пр…

Чем статический анализ отличается от предупреждений компилятора?

18 Авг 2014

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

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

0274_AnalyzerWarning_ru/image1.png

Анализ компиляторами

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

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

Сторонние анализаторы

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

На примере Visual C++ Compiler и PVS-Studio

В компиляторе Visual C++ есть диагностика C4265, выдающая предупреждения на объявление класса без виртуального деструктора. Это очень полезная диагностика, но она выдаёт предупреждения на все классы, не имеющие виртуального деструктора, поэтому по умолчанию она выключена.

Аналогичная диагностика V599 есть и у статического анализатора PVS-Studio. Будучи специализированным инструментом в этой области, анализатор имеет более интеллектуальный алгоритм, выдающий предупреждение только в том случае, если в базовом конструкторе есть хотя бы одна виртуальная функция и объект этого класса уничтожается с помощью оператора delete.

Другой пример связан с использованием функции memset. Рассмотрим следующий пример кода.

void Foo()
{
  char password[MAX_PASSWORD_LEN];
  InputPassword(password);
  ProcessPassword(password);
  memset(password, 0, sizeof(password));
}

Здесь предполагается очистить буфер, содержащий пароль. Этот код является полностью корректным с точки зрения компилятора, но вызов функции memset будет удалён компилятором без предупреждений, если запустить его с ключом "/O2". Подобное место находит анализатор PVS-Studio с помощью диагностики V597.

Правильный код выглядит следующим образом:

void Foo()
{
  char password[MAX_PASSWORD_LEN];
  InputPassword(password);
  ProcessPassword(password);
  RtlSecureZeroMemory(password, sizeof(password));
}

Для очистки буферов, содержащих приватную информацию, необходимо использовать специальную функцию RtlSecureZeroMemory.

Заключение

В заключение отметим основные моменты о средствах анализа исходного кода:

  • Анализ кода не является основной задачей компилятора.
  • Использование различных компиляторов для анализа затруднительно, хотя и желательно.
  • Компиляторы охватывают небольшой перечень распространённых ошибок.
  • Статические анализаторы специализируются только на анализе.
  • Статические анализаторы имеют обширную базу диагностических правил.
  • Идеология некоторых диагностик не исключает ложные срабатывания.
  • Можно использовать различные анализаторы, независимо от используемого компилятора.

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

Популярные статьи по теме
Обзор плагина PVS-Studio для Visual Studio Code

Дата: 02 Фев 2023

Автор: Андрей Москалёв

Благодаря новому плагину PVS-Studio преимущества статического анализа теперь доступны и при работе с редактором Visual Studio Code. В этой статье мы разберём использование плагина от этапа установки …
Изменения в PVS-Studio, о которых полезно знать

Дата: 31 Янв 2023

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

В этой статье расскажу о том, что появилось в PVS-Studio за последние три года, и чем это полезно пользователям анализатора. Статья модульная: можно не читать от начала до конца, а посмотреть только …
C++ — язык 2022 года. Почему так, и что с другими языками?

Дата: 20 Янв 2023

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

C++ становится языком 2022 года по версии TIOBE, обгоняя Python. Rust, C#, Go и прочие — далеко позади. Странно? Сейчас разберёмся.
PVS-Studio в 2022 году

Дата: 19 Янв 2023

Автор: Полина Алексеева

На дворе январь 2023, а значит, самое время подвести итоги уже прошлого 2022 года. Мы расскажем, чем занимались, и покажем, что нового появилось в анализаторе за это время. Давайте вместе взглянем на…
PVS-Studio: 2 фишки для быстрого старта

Дата: 08 Дек 2022

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

В этой заметке расскажу, как легко начать использовать PVS-Studio. Рассмотрим два сценария: когда вы пробуете анализатор впервые и когда внедряете его в проект.

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

Следующие комментарии next comments
close comment form
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо