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

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

Другим названием этой заметки может стать «Почему мне больше не интересно быть российским MVP в номинации Visual C++». Первая ассоциация, которая может возникнуть у читателя, что мне больше не интересен отживший своё язык. Такие ассоциации меня очень огорчают. C++ живее всех живых. К сожалению, в России многие про это не знают и уверены, что весь мир давно программирует только на C#, PHP, Python и иных новомодных языках. Это очень странно, и я чувствую себя в этой пустыне одиноко. Про это и будет моя статья.

В последнее время мне часто стали попадаться статьи, где ставится знак равенства между малым бизнесом и неудачниками. Пример одной из последних подобных статей: "Сергей Белоусов о зомби-стартапах от которых никакого толку, а избавиться жалко". Краткий смысл: если компания живет, но не развивается, то значит это провальный проект и пора переходить к новому. Я не согласен с таким направлением мысли. Не могут все компании расти и быть грандиозно успешными. И в этом нет ничего плохо. Если компания живет, это уже хорошо. Они не зомби, а просто нашедшие свою нишу компании. Малый бизнес это замечательно.

Разработчики поисковиков типа Google/Яндекс и разработчики инструментов статического анализа кода решают в каком-то смысле очень похожую задачу. И те, и другие должны предоставить пользователю некоторую выборку с ресурсами, которые «отвечают» желаниям пользователя. Нет, конечно, в идеале разработчики поисковиков хотели бы ограничиться кнопкой «Мне повезет!» (I'm Feeling Lucky). А разработчики инструментов анализа кода хотят выдавать только список реальных ошибок в коде. Но реальность как всегда накладывает ограничения. Хотите узнать, как мы сражаемся с жестокой реальностью при разработке PVS-Studio?

Продолжу рассказы о том, как программисты ходят по краю, даже не подозревая об этом. Поговорим об операциях сдвига <<, >>. Принципы работы операторов сдвига очевидны и многие программисты даже не знают, что их использование согласно стандарту Си/Си++ может приводить к неопределенному или к неуточненному поведению (undefined behaviour/unspecified behavior).

Аннотация

Эта статья будет интересна тем, кто продвигает свои собственные программные продукты в интернете. Статья исключительно практическая. Она представляет собой отчёт о некоторых действиях, которые мы осуществляли в последнее время для продвижения продукта PVS-Studio. Я расскажу, что работает, что не работает и поделюсь сопутствующими мыслями.

Прошло более года, как мы проверили Notepad++ с помощью PVS-Studio. Интересно посмотреть, насколько анализатор PVS-Studio стал лучше, и что было исправлено в Notepad++ из прежних ошибок.

В этот раз я хочу поговорить о функции printf. Все наслышаны об уязвимостях в программах, и что функции наподобие printf объявлены вне закона. Но одно дело знать, что лучше не использовать эти функции. А совсем другое — понять почему. В этой статье я опишу две классических уязвимости программ, связанных с printf. Хакером после этого вы не станете, но, возможно, по-новому взгляните на свой код. Вдруг, вы реализуете аналогичные уязвимые функции, даже не подозревая об этом.

СТОП. Подожди читатель, не проходи мимо. Я знаю, что ты увидел слово printf. И уверен, что автор статьи сейчас расскажет банальную историю о том, что функция не контролирует типы передаваемых аргументов. Нет! Статья будет не про это, а именно про уязвимости. Заходи почитать.

Захотелось написать несколько небольших заметок о том, как программисты на Си/Си++ играют с огнем, не подозревая об этом. Первая заметка будет про попытки явно вызвать конструктор.

Это уже четвертая заметка, где я хочу поделиться полезными наблюдениями о паттернах ошибок и том, как можно с ними бороться. В этот раз я затрону такую тему, как обработка редких и аварийных ситуаций в программах. Рассматривая множество программ, я пришел к выводу, что код обработки ошибок в Си/Си++ программах — одно из самых ненадежных мест.
К чему приводят такие дефекты? Программа, вместо того, чтобы выдать сообщение «файл X не найден», падает и заставляет пользователя гадать, что он не так делает. Программа для работы с базой данных выводит невразумительное сообщение, вместо того, чтобы сообщить, что неверно заполнено одно из полей. Попробуем сразиться с этой разновидностью ошибок, которые досаждают нашим пользователям.

Компания Intel проводит множество программ, связанных с обучением, организует конкурсы по программированию, приглашает на встречи и бесплатные конференции. К сожалению, часто это проходит мимо, и человек, случайно потом, узнав про уже завершившееся мероприятие, огорчается, что не принял в нём участие. Кстати, участие в конкурсах Intel часто приводит к тому, что и сам участник потом оказывается в Intel. Уже пару раз сам наблюдал такую картину. На одной встрече человек приехал за призом, а на следующий год — раз, и уже сам с бейджиком «Сотрудник Intel». Так что имейте в виду. :)

Однако, чтобы получить внимание со стороны Intel, необязательно сражаться на олимпиадах, есть и другие интересные и полезные пути. Например, можно стать участником сообщества Intel Software Network (ISN) и автоматически начать участие в конкурсе «Мастер программирования». Именно про эту программу я и хотел немного рассказать.

Компания id Software имеет лицензию на PVS-Studio. Тем не менее, мы решили проверить исходные коды Doom 3, которые недавно были выложены в сеть. Результат — ошибок найдено мало, но всё-таки найдено. Я предполагаю, что это можно объяснить так.

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

Для тех, кто интересуется данной тематикой, предлагаю вниманию фрагменты кода, на которые указал анализатор PVS-Studio. Как всегда напоминаю, что рассматриваю только некоторые предупреждения. Другие участки проекта требуют знания структуры программы, и я их не изучал.

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

1. Статический анализатор это продукт разового применения.
2. Профессиональные разработчики не допускают глупых ошибок.
3. Динамический анализ лучше чем статический.
4. Программисты хотят добавлять свои правила в статический анализатор.

Прогресс не стоит на месте. Развивается и мой любимый статический анализатор кода PVS-Studio. И недавно я понял, что те проекты, которые мы уже проверяли, можно вполне проверять заново. Писать про это новые статьи как-то странно и вряд ли они получатся интересными. Однако одну такую статью я всё-таки думаю надо сделать. Она станет еще одним аргументом в пользу утверждения, что настоящую пользу от статического анализа можно получить только при его регулярном использовании, а не при проверках от случая к случаю. Итак, посмотрим, что же удалось найти нового интересного в проекте Intel IPP Samples.

Проверив код ReactOS, я смог исполнить сразу три своих желания. Во-первых, давно хотелось написать статью об обыкновенном проекте. Не интересно проверять код таких проектов, как Chromium. Он слишком качественен и, на поддержание этого качества тратятся ресурсы, недоступные в обыкновенных проектах. Во-вторых, появился хороший пример, на котором можно показать, как необходим статический анализ в большом проекте, особенно если он разрабатывается разнородным распределенным коллективом. В-третьих, я получил подтверждение, что PVS-Studio становится всё лучше и полезнее.

Мы случайно проверили проект Clang. Думаю, результат будет любопытен ряду разработчиков. Подробности под катом.

В последнее время, рассказывая о проверке очередного проекта, я всё время повторял, что это очень качественный код и ошибок в нём практически не найдено. Примером может служить анализ таких проектов, как Apache, MySQL, Chromium. Почему мы выбираем такие приложения, я думаю понятно. Про них всех знают и никому не интересно, какие ужасы можно найти в дипломной работе студента Васи. Однако иногда мы поверяем и те проекты, которые просто случайно попали под руку. Некоторые такие проекты оставляют тяжёлые впечатления в моей тонкой и ранимой душе. В этот раз мы проверили Intel® Energy Checker SDK (IEC SDK).

В этот раз с помощью PVS-Studio мы проверили Apache HTTP Server. Как и ожидалось, нашли в нём ошибки. Ошибок мало. Это тоже ожидаемо.

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

Это третья статья, где я хочу рассказать про новую пару приёмов при программировании, которые помогут сделать код более простым и надежным. С предыдущими двумя заметками можно познакомиться здесь [1] и здесь [2]. В этот раз примеры будут взяты из проекта Qt.