Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

PVS-Studio наконец то добрался до Boost

Anna | 25.06.2014 | нет комментариев

Boost and PVS-Studio

Мы теснее давным-давно хотели проверить библиотеку Boost. У нас не было уверенности, что итогов проверки хватит на статью. Впрочем, желание не пропадало. Два раза мы пытались сделать это, но отступали, не разобравшись, как заменить вызов компилятора на вызов PVS-Studio.exe. Сейчас мы вооружились новым инструментарием, и третья попытка оказалась благополучной. Выходит, допустимо ли обнаружить в Boost ошибки?

Boost

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

  • Сайт библиотеки Boost.
  • Wikipedia. Boost.
  • Скачать Boost.

Boost представляет собой «тяжёлый» код, в котором энергично применяются трудные образцы. Эта библиотека в каком-то смысле является тестом для компиляторов. Зачастую бывает, что какой-то компилятор горазд скомпилировать только часть планов из нынешней библиотеки Boost.

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

Напомню существующие варианты проверки планов с поддержкой PVS-Studio.

Если есть обычный план для Visual Studio либо Embarcadero C Builder

Тут всё легко. Обзор плана может быть исполнен непринужденно из среды разработки. Иной вариант — запустить PVS-Studio из командной строки и на выходе получить файл с итогами проверки. Данный режим комфортно применять в системах постоянной интеграции (скажем Cruise Control, Draco.NET либо Team Foundation Build). Подробнее данный режим описан в документации. О взаимодействии с системами постоянной интеграции дозволено посмотреть тут.

Если плана нет (либо план по сути представляет собой замаскированный makefile)

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

Именно данный подход нам и следовало применять, Дабы проверить Boost. Жалко, мы оказались магами неудовлетворительного яруса либо легко ленивыми. Не получалось разобраться в системе сборки, Дабы передать консольной версии анализатора все нужные параметры.

На поддержка нам пришел новейший 3-й вариант проверки планов

О этом новом режиме теснее упоминал мой сотрудник в недавней заметке “Из подвала секретной лаборатории разработчиков PVS-Studio“. Не нужно полновесно интегрироваться в систему сборки. Довольно легко получитьпрепроцессированные *.i файлы. Это гораздо проще. Именно так мы и поступили.

После этого, применяя прототип нового инструмента (PVS-Studio Standalone), мы исполнили обзор всех *.i файлов и получили долгожданный отчёт. В этой же программе дозволено комфортно трудиться со списком ошибок и вносить исправления в код.

Я верю, мы включим данный инструмент в состав дистрибутива через несколько версий. Допустимо, это произойдет в PVS-Studio 5.10.

Пара слов о режиме, которого нет, но о котором мечтаем

Мы помаленьку подбираемся к отслеживанию действий компилятора. Данный режим также будет относиться к инструменту PVS-Studio Standalone. Будут отслеживаться все запуски компилятора и собираться ключи его запуска. Таким образом, будет довольно исполнить следующие действия. Приказать — «следи». Собрать план с поддержкой всякий системы сборки. Сказать — «готово». И анализатор будет знать, как сейчас проверять план. Безусловно, если конструкция плана либо параметры изменится, данный процесс придётся повторить. Хорошо, помечтали, а сейчас возвратимся к проверке Boost.

чувство безнадежности

Я был готов, что статью про Boost написать не получится. У этого печального предположения были следующие предпосылки.

Огромное число компиляторов и инструментов

Boost собирается огромным числом компиляторов. Какими-то Отчасти, какими-то всецело. Я не проводил постижения этого вопроса. Но, как я понимаю, Boost хорошо собирается с поддержкой Visual C , Intel C , Sun Studio, Compaq C , GCC, Clang. Всякий компилятор владеет своими уникальными диагностическими способностями. А их суммарное применение должно обеспечить дюже высокое качество кода. Один компилятор найдёт ошибку A, 2-й ошибку B и так дальше.

Больше того, библиотека Boost является своего рода полигоном испытания разных инструментов и статических анализаторов кода. От того что в Boost энергично применяются разные современные вероятности языка Си , то неизменно увлекательно знать сумеет ли инструмент разобраться с таким кодом. В итоге, Boost проверен и перепроверен разными анализаторами кода.

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

Огромное число пользователей

Библиотека Boost применяется во многих планах. Одно время мы и сами применяли Boost в плане PVS-Studio (тогда ещё Viva64). Применялись механизмы для работы с регулярными выражениями, с конфигурационными файлами и пара других мелочей. Потом мы осознали, что регулярные выражения это тупиковый путь, и понемногу они исчезли из кода. Таскать Boost только из-за конфигурационных файлов было подозрительно. Тем больше выяснились некоторые неприятные недочеты. Скажем, в имени файла невозможно применять ‘#’. Данный символ считается за предисловие комментария. В нашем определенном случае Boost не прижился, впрочем, это, безоговорочно, дюже пригодная библиотека.

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

Образцы

В Boost много шаблонных классов. Их примерно немыслимо проверить, если они не инстанцируются. Скажем ,Visual C вообще не разбирает шаблонные классы, если они не применяются. В неиспользуемом классе дозволено написать всякую белиберду и файл удачно скомпилируется Довольно, Дабы соблюдалось число открывающихся и закрывающихся скобок и кавычек (), <>, {}, [], “”, ”.

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

template <typename T>
bool IsNAN(T x) { return x != x; }

Эта функция определяет, является ли значение переменной «не числом» (Not-a-Number). Эта функция имеет толк для типов float/double/long double. Для целочисленных типов такое сопоставление безрезультатно, и указывает на присутствие ошибки.

Как быть, если тип неведом? Неразрешимый вопрос. Для полновесной проверки все образцы обязаны применяться во всех допустимых вариантах. Больше того. Образцы необходимо ещё разобрать. А это трудная задачка. Скажем, у PVS-Studio есть ряд задач с этим. Что-то он может разобрать и даже попытаться инстанцировать, а что-то нет.

В любом случае обзор образцов дюже неблагодарное дело. А в Boost их полным полно.

Оценка шансов

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

Обнаружить 3-4 ошибки в Boost я посчитал бы громадным достижением.

Давайте посмотрим, что удалось обнаружить PVS-Studio 5.06 в Boost 1.55 (скачана версия на этапе разработки).
Источник: programmingmaster.ru<

Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB