Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого феномена, поэтому и решил о нём написать. Я назвал его «эффектом последней строки».

Я проверил проект OpenMW с помощью PVS-Studio и написал эту крошечную статью. Нашлось слишком мало ошибок. Но меня просили написать про проверку этого проекта статью, и вот она.

Tesseract — свободная компьютерная программа для распознавания текстов, разрабатываемая компанией Google. В описании проекта говорится: «Tesseract is probably the most accurate open source OCR engine available». А давайте попробуем, сможет ли статический анализатор PVS-Studio распознать какие-то ошибки в этом проекте.

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

Поддержка проектов, написанных на C++/CLI не является приоритетным направлением в PVS-Studio. Таких проектов достаточно мало, но тем не менее время от времени мы сталкиваемся с ними. Компания Microsoft на данный момент не планирует прекратить поддержку языка C++/CLI, поэтому мы решили всё-таки поддержать эту разновидность языка.

Мы постоянно проверяем открытые проекты на языке Си/Си++. Но почти всегда, это проекты, разрабатываемые в Visual Studio. А вот Embarcadero C++ Builder мы как-то обделили вниманием. Нужно исправляться и сегодня мы проверили проект WinSCP.

Инструменты статического анализа кода позволяют устранить множество ошибок ещё на этапе написания текста программы. Например, можно быстро выявить и устранить опечатки. Некоторые программисты искренне уверены, что они не делают опечатки и глупые ошибки. Это не так. Такие ошибки делают все. Эта статья послужит хорошим демонстрационным примером. Опечатки можно найти даже в таком качественном и оттестированном проекте, как Qt.

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

19 марта 2014 года Unreal Engine 4 стал доступен для всех желающих. Цена подписки всего 19$ в месяц. Исходные коды также выложены на github репозиторий. С этого момента нам поступила масса сообщений на почту, в твиттер и так далее, с просьбой проверить этот игровой движок. Мы удовлетворяем просьбу наших читателей. Давайте посмотрим, что интересного можно найти в исходном коде с помощью статического анализатора кода PVS-Studio.

Зарекался больше не касаться эмуляции 3DO консоли, каюсь. Но тут у меня появилась возможность поработать с такой экзотической штукой как статический анализатор кода, а именно PVS-Studio. Первое на чем я решил опробовать анализатор конечно же стал мой эмулятор консоли 3DO (Phoenix Project). В начале 90-х была такая приставка, первая 32-х битная консоль с CD-приводом, помню нам с братом ее отец из Москвы привез, с тех пор никак оторваться не могу. Ну а раз подвернулся случай, то за одно и все основные проекты по эмуляции 3DO проверим. Итак, поехали…

Недавно компания Microsoft сделала подарок всем программистам, которые хотят покопаться в чем-то интересном. Microsoft открыли исходный код MS-DOS v 1.1, v 2.0 и Word for Windows 1.1a. Операционная система MS-DOS написана на ассемблере, и к ней анализатор не применим. А вот Word написан на языке Си. Исходным кодам Word 1.1a почти 25 лет, однако нам кое-как удалось их проверить. Конечно никакой практической ценности в этой проверке нет. Just for fun.

Я временами бываю озадачен, рассматривая ошибки в очередном программном проекте. Многие из этих ошибок живут в проектах годами. Смотришь на сотню ляпов в коде и удивляешься, как программа вообще работает. И ведь как-то работает. Ей даже пользуются. Причем, я говорю не о коде, рисующем покемона в игре. А, например, о математических библиотеках. Да, вы верно догадались. В этой статье пойдет речь о проверке кода математической библиотеки Scilab.

Сейчас в PVS-Studio мы делаем бомбу!

В следующей версии PVS-Studio 5.15 сможет проверять проекты, которые собираются абсолютно в любой сборочной системе: Makefile, Visual Studio Project, собственная система сборки на основе Python, Bash или что там еще… Теперь мы можем просто «наблюдать» за вызовами компилятора. И собирать всю необходимую информацию для запуска анализа автоматически. Более того, это работает с любым (разумным) компилятором C/C++, который запускается в Windows. Хотите подробностей?

В этот раз интересные примеры ошибок нам преподнёс микромир. Мы проверили с помощью анализатора кода PVS-Studio открытый проект μManager. Это программный пакет для автоматизированного получения изображения с микроскопа.

Мы решили сделать небольшую паузу в тематике статического анализа кода. Ведь блог C++ читают и те, кто пока еще не использует эту технологию. А между тем в мире C++ происходят явления, которые оказывают влияния на такую «устоявщуюся» тему, как 64-битный мир. Речь идет о том как стандарт C++11 влияет и помогает (если есть чем) в разработке корректных 64-битных программ. Сегодняшняя статья как раз об этом.

Авторы: Евгений Рыжков (EvgeniyRyzhkov), Андрей Карпов (Andrey2008), Павел Еремеев (Paull), Святослав Размыслов (svyatoslavmc).


Мы провели подробное сравнение четырёх анализаторов Си/Си++ кода: CppCat, Cppcheck, PVS-Studio и статический анализатор, встроенный в Visual Studio 2013. Это серьезное исследование, на которое нами было потрачено около 170 человеко-часов и которое, на наш взгляд, хорошо отражает картину, существующую на данный момент.

Мы закончили сравнивать статические анализаторы кода Cppcheck, PVS-Studio и анализатор встроенный в Visual Studio 2013. В ходе этого было проверено более 10 открытых проектов. И про некоторые из них можно написать статьи. Вот очередная такая статья о результатах проверки проекта CryEngine 3 SDK.

В списке вопросов, которые всегда задают нам после прочтения наших статей есть вопрос: «А вы проверяете код своего анализатора им самим?». И дается ответ в том ключе, что у нас всегда проверяется код во время написания с помощью режима инкрементального анализа (проверки файлов сразу после компиляции). А также запускаются ночные проверки для всего кода. И в связи с этим мы, к сожалению (ирония), никогда не сможем написать статью про ошибки в наших программных продуктах.

Однако сегодня – именно статья про одну нашу ошибку и про то, сколько она нам стоила. Заинтриговал?

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

Сейчас мы заняты большой задачей. Мы хотим провести сравнение четырёх анализаторов кода: Cppcheck, PVS-Studio и Visual Studio 2013 (встроенный анализатор кода). Для этого мы решили проверить не менее 10 открытых проектов и проанализировать отчёты, которые выдадут анализаторы. Это очень трудоёмкая задача и пока она не завершена. Но так как ряд проектов уже проверен, то про некоторые из них можно написать статьи. Чем я сейчас и займусь. Для начала опишу, что интересного удалось найти с помощью PVS-Studio в Firebird.