Эта статья является переводом Сообщение блога Хартмут Кайзер об опыте использования PVS-Studio Х.
П.
Х.
— Библиотека C++ для распределенных/параллельных вычислений любого масштаба.
Когда-то мы уже пользовались пробной версией анализатора PVS-Studio для HPX, и тогда она нам запомнилась многословием.
В последнее время появилось много статей об этой утилите, а так как.
Прошло много времени с момента ее использования, мы решили связаться с разработчиками, чтобы узнать, готовы ли они поддержать наш продукт с открытым исходным кодом.
Мы были очень рады, когда получили лицензию на 1 год в обмен на статью о найденных проблемах.
Общие впечатления
Скачать PVS-Студио V5.26 , у меня не возникло проблем с установкой его как расширения для Visual Studio 2013 Professional, хотя я бы предпочел протестировать его с версией 2015RC1, моей основной средой разработки.К сожалению, VS 2015 на данный момент не поддерживается, но будем надеяться, что это произойдет вскоре после выхода нового релиза от Microsoft. Интеграция PVS-Studio в Visual Studio произвела очень хорошее впечатление.
Одна дополнительная кнопка меню обеспечивает доступ ко всем командам и опциям.
Все диагностические сообщения отображаются в специальном окне, из которого можно напрямую перейти к исходному коду.
Вы также можете открыть контекстно-зависимую веб-справку, в которой описывается каждая диагностика отдельно.
Все так, как нам хотелось бы.
Сообщения имеют 3 различных уровня серьезности: высокий, средний и низкий и, в свою очередь, группируются в 3 категории анализа: общий, оптимизационный и 64-битный анализ совместимости.
Пользовательский интерфейс позволяет ограничить отображаемую диагностику и фильтровать результаты.
Для основного модуля HPX анализатор сгенерировал около 70 сообщений примерно из 1000 файлов .
h и .
cpp (~140000 строк кода), что, на мой взгляд, неплохо (высокая степень серьезности: 5, средняя: 44, низкая: 21).
Первоначальный анализ на моем ноутбуке занял около 10 минут.
Примеры ошибок
Мне очень хотелось увидеть скрытые ошибки в HPX. Наша команда очень внимательно относится к качеству кода, и каждый запрос на включение проверяется как минимум одним разработчиком перед объединением в основную ветку.Поэтому я был уверен, что анализатор ничего не найдет. Во-первых, давайте посмотрим на ошибки высокой серьезности.
Четыре из них были очень похожи и имели общий характер:
Этот код десериализует полиморфный объект через указатель на базовый класс.template <typename Archive> void load(Archive& ar) { actions::manage_object_action_base* act = 0; ar >> hpx::serialization::detail::raw_ptr(act); // V522: Dereferencing of the null pointer 'act' might take place. HPX_ASSERT(act->is_valid()); // .}
Мы знаем, что raw_ptr(act) динамически создает новый объект, присваивая его адрес переданному указателю.
Мы также знаем, что в случае возникновения ошибки функция выдает исключение.
Все это можно было бы увидеть статическим анализатором, т.к.
весь модуль сериализации в HPX находится в заголовках.
Анализатор видимо этого не увидел и выдал ошибки.
К счастью, вы можете одним щелчком мыши явно указать PVS-Studio игнорировать эту ошибку, что добавит магический комментарий типа //-V522 — очень удобно.
Более того, PVS-Studio предоставляет множество возможностей подавления сообщений по файлам или каталогам, по шаблонам в именах файлов — все варианты легко доступны и хорошо объяснены.
Вторая ошибка меня насторожила: #define HPX_VERSION_MAJOR 0
#define HPX_VERSION_MINOR 9
#define HPX_VERSION_SUBMINOR 11
std::string full_version_as_string()
{
// V609 Mod by zero. Denominator ‘0’ == 0.
return boost::str(
boost::format("%d.%d.%d") %
HPX_VERSION_MAJOR % HPX_VERSION_MINOR %
HPX_VERSION_SUBMINOR);
}
Мне потребовалось некоторое время, чтобы понять, что хотел сказать анализатор, потому что.
оператор% из Boost.Format мне показался совершенно неприметным.
Однако даже если бы оператор% не был перегружен и код действительно был проблематичным, сообщение об ошибке все равно было бы неясным.
Эту проблему я «решил» тем же способом — подавлением сообщения.
Последнее сообщение «высокой серьезности» стало результатом оптимизации: // V808 'hostname' object of 'basic_string' type was created
// but was not utilized.
std::string hostname = boost::asio::ip::host_name();
И анализатор был прав, переменная «hostname» в данном контексте вообще не использовалась.
Ни один из компиляторов, которые мы используем для регулярного тестирования на более чем 20 платформах, раньше не обнаруживал этого — отличный момент! Сообщения средней и низкой степени серьезности в основном были связаны с незначительными проблемами совместимости 32-битных/64-битных систем, такими как неявное приведение целых чисел со знаком к большим целым числам без знака (например, int32_t --> uint64_t).
Но две ошибки оказались настоящими багами: int runtime_support::load_components(util::section& ini)
{
// load all components as described in the configuration information
if (!ini.has_section("hpx.components")) {
// V601 The 'true' value is implicitly cast to the integer type.
return true; // no components to load
}
// .
}
Само сообщение прекрасно указывает на проблему: однажды мы изменили тип возвращаемого значения функции с bool на int, но забыли изменить одно из возвращаемых выражений.
Это может создать проблемы, которые трудно воспроизвести в будущем.
Другая ошибка оказалась более серьезной: struct when_each_frame
{
// .
private: // V690 Copy constructor is declared as private in the // 'when_each_frame' class, but the default '=' operator // will still be generated by compiler. It is dangerous // to use such a class. when_each_frame(); when_each_frame(when_each_frame const&); public: // .
};
Это действительно замечательный момент, особенно потому, что мы добавили объявление конструктора в качестве обходного пути для старых версий gcc, которые неправильно создавали реализации по умолчанию.
В конце концов, я был рад потратить время на запуск анализатора всей кодовой базы HPX. Я был рад видеть, что никаких серьезных проблем обнаружено не было, что подтверждает нашу политику проверки, которую мы ввели довольно давно.
Я также решил добавить PVS-Studio в наш непрерывный процесс интеграции, который запускается при каждом коммите.
Заключение
Статический анализ определенно имеет значение.Запуск утилит типа PVS-Studio хоть и требует некоторого времени и усилий, но, на мой взгляд, является хорошей инвестицией времени и денег.
Компиляторы не подходят для глубокого анализа, который делает PVS-Studio, так как в противном случае это значительно увеличит время компиляции.
Одной из наиболее полезных функций для нас стала простая интеграция в процесс CI. Поскольку мы ежедневно проводим тесты на различных платформах (в том числе Windows), результаты анализа становятся доступны разработчикам, работающим на других ОС (Linux, Mac OS).
Еще одна приятная особенность PVS-Studio — он запускает анализ каждый раз после успешной сборки проекта.
Удивительно, но это не добавляет особых затрат к обычному процессу сборки, а также обеспечивает обратную связь по тонким проблемам кода на самых ранних стадиях реализации.
Я оставил эту опцию включенной, чтобы оценить полезность инструмента во время процесса.
Разбирая сгенерированные сообщения, я был удивлён, что, хотя у утилиты есть время на максимально глубокий анализ, PVS-Studio не смог проанализировать перегрузки некоторых операторов для определения недефолтной семантики.
Это продемонстрировал пример оператора% из Boost.Format. Согласен – это действительно очень деликатный момент, и я не уверен, что в этом случае можно поставить правильный диагноз.
С другой стороны, именно здесь, при глубоком анализе семантики кода, инструмент должен проявить всю свою мощь.
Если вас интересует HPX, создайте форк библиотеки с помощью github .
Теги: #C++ #Visual Studio #высокая производительность #pvs-studio #статический анализ кода
-
Новые Рендеры «Материнского Корабля» Apple
19 Oct, 24 -
Спамеры Любят Агент Mail.ru
19 Oct, 24
