Блог с сайта www.viva64.com

Проверка проекта Quake III Arena GPL

Как известно, компания id Software выложила исходные коды многих своих игр. Мы уже проверяли некоторые из этих проектов. На этот раз мы решили проанализировать исходный код Quake III Arena GPL. Для анализа использовался статический анализатор PVS-Studio версии 4.54.

Не зная брода, не лезь в воду. Часть вторая

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

Как мы решали задачу реализации trial-режима в анализаторе кода PVS-Studio

Для многих разработчиков программного обеспечения, выбор и изменение модели trial-режима является одной из самых трепетных и обсуждаемых задач. Для одних программ придумать модель проще, для других сложно. А некоторых людей не покидает вопрос: "Мы всё правильно сделали?". Актуальна задача выбора trial-модели и для нас, разработчиков PVS-Studio. Мы решили поделиться некоторыми сопутствующими мыслями и рассказать о том, какой новый вариант мы придумали. Надеемся, что наши рассуждения и некоторые мысли окажутся полезными и другим разработчикам.

Не зная брода, не лезь в воду. Часть первая

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

Советы по повышению скорости работы PVS-Studio

Эта запись устарела. Читайте "Советы по повышению скорости работы PVS-Studio" в документации..

О пользе автоматической фильтрации одинаковых сообщений

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

"Проверьте еще вот этот проект..."

Мы считаем, что лучший способ продвижения нашего статического анализатора кода PVS-Studio – это проверка с его помощью известных открытых проектов (вроде Chromium, Clang, WinMerge и многих-многих других) и написание статей по результатам проверки. Это не простая задача, так как, к сожалению, PVS-Studio – всего лишь инструмент, а не чудо-программа, которая сама ищет все ошибки. Часто нам пишут люди с просьбой проверить тот или иной проект и написать об этом статью.

Диалог Windows Error Reporting

Как и для любой Windows native программы, при работе анализатора PVS-Studio (а именно процесса PVS-Studio.exe) существует вероятность возникновения программно необрабатываемого исключения, например при переполнении стека вызовов. Операционные системы семейства Windows, начиная с версии Windows Vista, при возникновении необработанного исключения в программе генерируют специальный диалог аварийного завершения работы, предлагающий закрыть или отладить такую программу.

О нашей библиотеке VivaCore

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

Что поражает меня при разработке статического анализатора кода

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