На форумах иногда можно увидеть людей, считающих, что предупреждений компилятора более чем достаточно для контроля над основными типами ошибок в коде программ. Я хочу показать, что это не так.
Специализированные инструменты статического анализа и стандартные средства предупреждений в компиляторах направлены на повышение качества исходного кода и минимизацию потенциальных, трудно уловимых отладкой, ошибок. Так или иначе, сообщения компилятора выдаются на основе статического анализа исходного кода во время компиляции, но использование для диагностирования потенциальных ошибок того или иного способа имеет множество отличий как по качеству предупреждений, так и по возможностям использования.
Первостепенная задача компилятора состоит в получении бинарного кода из компилируемых исходных файлов. Скорость компиляции – одна из важных его характеристик, поэтому на статический анализ исходного кода отводится не так много времени, чтобы проводить глубокий анализ или оперировать большим количеством диагностических правил. Поэтому компиляторы сообщают только о самых распространённых проблемных конструкциях в коде.
Как продукты разных компаний, многие компиляторы могут сильно отличаться возможностями в выдаче сообщений на подозрительные участки исходного кода, поэтому использование разных компиляторов также может повысить качество программ. Но зачастую нет возможности скомпилировать одну программу разными компиляторами, даже под одну операционную систему. Некоторые компиляторы могут предоставлять собственные расширения языка, неподдерживаемые другими компиляторами, использование которых ухудшает переносимость исходного кода. Также использование платформозависимых конструкций затруднит проверку программы другим компилятором, если он существует только для другой операционной системой.
По-другому обстоят дела при использовании специализированных инструментов статического анализа. Будучи развивающимися в одном направлении, такие инструменты являются более гибкими и развитыми в сфере анализа исходного кода программ. В отличии от компиляторов, статические анализаторы предоставляют больше диагностических правил, многие из которых диагностируют очень нестандартные и не самые распространённые ошибки.
В компиляторе 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.
В заключение отметим основные моменты о средствах анализа исходного кода:
Использование различных инструментов статического анализа, отличающихся методологией анализа, безусловно повысит качество кода вашей программы.