Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил общего назначения. Эта функциональность на данный момент является бесплатной.
Урок 8. Статический анализ для выявления 64-битных ошибокTatyanazaxarova
Статический анализ кода - методология выявления ошибок в программном коде, основанная на просмотре программистом участков кода, помеченных статическим анализатором. Помеченные участки кода с большой вероятностью содержат ошибки определенного типа.
Трудности сравнения анализаторов кода или не забывайте об удобстве использованияTatyanazaxarova
Желание пользователей сравнить между собой разные анализаторы кода понятно и естественно. Однако реализовать это желание совсем не так просто как может показаться на первый взгляд. Дело в том, что непонятно какие конкретно факторы между собой сравнивать.
Разница в подходах анализа кода компилятором и выделенным инструментомTatyanazaxarova
У компилятора и сторонних инструментов статического анализа кода есть общая задача - выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.
PVS-Studio, решение для разработки современных ресурсоемких приложенийTatyanazaxarova
Инструмент PVS-Studio
набор правил Viva64 для анализа 64-битных приложений;
набор правил VivaMP для анализа параллельных приложений;
набор правил для анализа общего назначения.
Лицензионная и ценовая политика PVS-Studio
Информация о компании ООО «СиПроВер»
В этот раз победу одержало добро. А вернее, исходные коды проекта Chromium. Chromium - один из лучших проектов, который мы проверяли с помощью PVS-Studio.
Статический анализ исходного кода на примере WinMergeTatyanazaxarova
Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам - WinMerge.
Урок 8. Статический анализ для выявления 64-битных ошибокTatyanazaxarova
Статический анализ кода - методология выявления ошибок в программном коде, основанная на просмотре программистом участков кода, помеченных статическим анализатором. Помеченные участки кода с большой вероятностью содержат ошибки определенного типа.
Трудности сравнения анализаторов кода или не забывайте об удобстве использованияTatyanazaxarova
Желание пользователей сравнить между собой разные анализаторы кода понятно и естественно. Однако реализовать это желание совсем не так просто как может показаться на первый взгляд. Дело в том, что непонятно какие конкретно факторы между собой сравнивать.
Разница в подходах анализа кода компилятором и выделенным инструментомTatyanazaxarova
У компилятора и сторонних инструментов статического анализа кода есть общая задача - выявление опасных фрагментов кода. Однако существует существенная разница в том, анализ какого типа они осуществляют. Я попробую на примере компилятора Intel C++ и анализатора PVS-Studio продемонстрировать различия подходов, и пояснить, чем они вызваны.
PVS-Studio, решение для разработки современных ресурсоемких приложенийTatyanazaxarova
Инструмент PVS-Studio
набор правил Viva64 для анализа 64-битных приложений;
набор правил VivaMP для анализа параллельных приложений;
набор правил для анализа общего назначения.
Лицензионная и ценовая политика PVS-Studio
Информация о компании ООО «СиПроВер»
В этот раз победу одержало добро. А вернее, исходные коды проекта Chromium. Chromium - один из лучших проектов, который мы проверяли с помощью PVS-Studio.
Статический анализ исходного кода на примере WinMergeTatyanazaxarova
Сегодня я хочу посвятить пост тематике, почему инструменты анализа исходного кода полезны вне зависимости от уровня знаний и опыта программиста. А польза такого анализа будет продемонстрирована на примере инструмента, который известен всем программистам - WinMerge.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
Получасовая презентация по Java 9. Конечно, рассказать можно много больше, да и часть выводов прозизносил вслух, но в любом случае, если интересна Java 9, то изучение можно начать со ссылок в конце презентации.
Критика, предложения приветствуются.
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Тестируем тесты с PIT (мутационное тестирование)Vitebsk Miniq
Презентация подготовлена по материалам выступления Евгения Барановского на витебском Dev Day MiniQ (https://vk.com/devdayminiq), который был проведен 15 сентября 2016.
Оптимизация трассирования с использованием Expression templatesPlatonov Sergey
В докладе будет рассказано о тех фундаментальных причинах, приводящих к неоптимальному коду в продукте, будет предложен подход, лишённый найденных недостатков.
Докладываемый подход опирается на технологию Expression Templates, которая позволяет уменьшить количество действий и объём ресурсов, которые требуются для выполнения неких промежуточных действий в процессе формирования каждой записи в журнал. Эта технология используется для уменьшения количества промежуточных операций при вычислении сложных математических выражений. Новизна докладываемого подхода в том, что тот же самый принцип, на котором основана технология Expression Templates можно применить для того, чтобы целенаправленно исключить те промежуточные действия, которые в конечном итоге приводят к неоптимальному коду.
Завершается доклад обсуждением полученного эффекта, путей возможного дальнейшего развития и возможностей применения этой же технологии в других задачах.
32 подводных камня OpenMP при программировании на Си++Tatyanazaxarova
С распространением многоядерных систем задача параллельного программирования становится все более и более актуальной. Данная область, однако, является новой даже для большинства опытных программистов. Существующие компиляторы и анализаторы кода позволяют находить некоторые ошибки, возникающие при разработке параллельного кода. Многие ошибки никак не диагностируются. В данной статье приводится описание ряда ошибок, приводящих к некорректному поведению параллельных программ, созданных на основе технологии OpenMP.
Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем вр...ScrumTrek
Автоматизация бизнес-процессов часто подразумевает интеграцию большого количества IT систем. При производстве такого ПО серьезной проблемой является сбор и анализ логов систем. Эта проблема актуальная и для системы FORIS, которая поддерживает бизнес МТС.
Мы разберем проблемы, которые подтолкнули к разработке системы Central Logging, обозначим решение этих проблем, узнаем, какое отношение имеет игра пинг-понг к разработке программного обеспечения, а так же, как Central Logging помогла нам меньше играть в пинг-понг и больше времени тратить на разработку новых задач для заказчика.
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
"Опыт создания системы управления сборкой и тестированием" (слайдкаст)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Presentation from https://heisenbug-piter.ru/en/talks/2018/spb/kkw6oivsoywayacggksmk/
Once upon a time, we got a requirement to finish all testing in 2 days despite the number of tests to run. That number grew, and grew, and grew, and now there are tens of millions of them. So this is a story about building a dam against the never-ending flood which turned out to be not that scary. You are very welcome to join and see it for yourself.
Неудачная попытка сравнить PVS-Studio (VivaMP) и Intel C/C++ ("Parallel Lint")Tatyanazaxarova
Изначально статья должна была носить название "Сравнение диагностических возможностей PVS-Studio (VivaMP) и Intel C/C++ Compiler ("Parallel Lint"). Отсутствие на данный момент достаточного количества информации о "Parallel Lint" ограничило возможности автора, и статья представляет собой предварительный вариант сравнения. Полный вариант статьи с корректным сравнением будет доступен читателю в будущем. Обратите внимание, что содержание статьи актуально на момент публикации. В дальнейшем возможно изменение диагностических возможностей обоих продуктов.
Что могут статические анализаторы, чего не могут программисты и тестировщикиAndrey Karpov
Одной из технологий выявления ошибок на ранних этапах является статический анализ кода. К сожалению, ряд инструментов реализуют анализ весьма поверхностно, что снижает доверие к методологии статического анализа в целом. Некоторые программисты начинают думать, что анализ кода — это нечто, базирующееся на регулярных выражениях и они сами легко найдут такие ошибки. На самом деле всё гораздо сложнее и интересней. Более того, многие ошибки невероятно сложно найти, если не использовать инструменты статического анализа кода. И в этом докладе будет продемонстрировано множество таких случаев. Послушав доклад, вы взглянете на статический анализ совсем по-новому. Дополнительно будет рассказано с чего начать, если вы захотите внедрить инструмент статического анализа в уже существующий процесс разработки.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
Получасовая презентация по Java 9. Конечно, рассказать можно много больше, да и часть выводов прозизносил вслух, но в любом случае, если интересна Java 9, то изучение можно начать со ссылок в конце презентации.
Критика, предложения приветствуются.
Интервью с Дмитрием Вьюковым – автором верификатора Relacy Race Detector (RRD)Tatyanazaxarova
Интервью с Дмитрием Вьюковым - автором инструмента Relacy Race Detector (RRD) для верификации параллельных приложений. В статье вы узнаете об истории создания RRD, его основных возможностях, а также о некоторых других аналогичных инструментах и их отличии от RRD.
Тестируем тесты с PIT (мутационное тестирование)Vitebsk Miniq
Презентация подготовлена по материалам выступления Евгения Барановского на витебском Dev Day MiniQ (https://vk.com/devdayminiq), который был проведен 15 сентября 2016.
Оптимизация трассирования с использованием Expression templatesPlatonov Sergey
В докладе будет рассказано о тех фундаментальных причинах, приводящих к неоптимальному коду в продукте, будет предложен подход, лишённый найденных недостатков.
Докладываемый подход опирается на технологию Expression Templates, которая позволяет уменьшить количество действий и объём ресурсов, которые требуются для выполнения неких промежуточных действий в процессе формирования каждой записи в журнал. Эта технология используется для уменьшения количества промежуточных операций при вычислении сложных математических выражений. Новизна докладываемого подхода в том, что тот же самый принцип, на котором основана технология Expression Templates можно применить для того, чтобы целенаправленно исключить те промежуточные действия, которые в конечном итоге приводят к неоптимальному коду.
Завершается доклад обсуждением полученного эффекта, путей возможного дальнейшего развития и возможностей применения этой же технологии в других задачах.
32 подводных камня OpenMP при программировании на Си++Tatyanazaxarova
С распространением многоядерных систем задача параллельного программирования становится все более и более актуальной. Данная область, однако, является новой даже для большинства опытных программистов. Существующие компиляторы и анализаторы кода позволяют находить некоторые ошибки, возникающие при разработке параллельного кода. Многие ошибки никак не диагностируются. В данной статье приводится описание ряда ошибок, приводящих к некорректному поведению параллельных программ, созданных на основе технологии OpenMP.
Кирилл Черятов. Эволюция системы логирования интеграционного ПО. Сокращаем вр...ScrumTrek
Автоматизация бизнес-процессов часто подразумевает интеграцию большого количества IT систем. При производстве такого ПО серьезной проблемой является сбор и анализ логов систем. Эта проблема актуальная и для системы FORIS, которая поддерживает бизнес МТС.
Мы разберем проблемы, которые подтолкнули к разработке системы Central Logging, обозначим решение этих проблем, узнаем, какое отношение имеет игра пинг-понг к разработке программного обеспечения, а так же, как Central Logging помогла нам меньше играть в пинг-понг и больше времени тратить на разработку новых задач для заказчика.
"Опыт создания системы управления сборкой и тестированием" (полная)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
"Опыт создания системы управления сборкой и тестированием" (слайдкаст)SPB SQA Group
Доклад посвящен вопросам создания и использования собственной системы управления процессами сборки и тестирования ПО. Описываются ключевые моменты построения таких систем, в частности: вопросы интерфейсов, быстродействия, качества и интеграции в общую инфраструктуру. Затрагиваются концепции встраивания качества в код, сбора и использования метрик ПО, неотделимости сборки от тестирования, автоматизированного ведения базы знаний об ошибках и другие.
Presentation from https://heisenbug-piter.ru/en/talks/2018/spb/kkw6oivsoywayacggksmk/
Once upon a time, we got a requirement to finish all testing in 2 days despite the number of tests to run. That number grew, and grew, and grew, and now there are tens of millions of them. So this is a story about building a dam against the never-ending flood which turned out to be not that scary. You are very welcome to join and see it for yourself.
Неудачная попытка сравнить PVS-Studio (VivaMP) и Intel C/C++ ("Parallel Lint")Tatyanazaxarova
Изначально статья должна была носить название "Сравнение диагностических возможностей PVS-Studio (VivaMP) и Intel C/C++ Compiler ("Parallel Lint"). Отсутствие на данный момент достаточного количества информации о "Parallel Lint" ограничило возможности автора, и статья представляет собой предварительный вариант сравнения. Полный вариант статьи с корректным сравнением будет доступен читателю в будущем. Обратите внимание, что содержание статьи актуально на момент публикации. В дальнейшем возможно изменение диагностических возможностей обоих продуктов.
Что могут статические анализаторы, чего не могут программисты и тестировщикиAndrey Karpov
Одной из технологий выявления ошибок на ранних этапах является статический анализ кода. К сожалению, ряд инструментов реализуют анализ весьма поверхностно, что снижает доверие к методологии статического анализа в целом. Некоторые программисты начинают думать, что анализ кода — это нечто, базирующееся на регулярных выражениях и они сами легко найдут такие ошибки. На самом деле всё гораздо сложнее и интересней. Более того, многие ошибки невероятно сложно найти, если не использовать инструменты статического анализа кода. И в этом докладе будет продемонстрировано множество таких случаев. Послушав доклад, вы взглянете на статический анализ совсем по-новому. Дополнительно будет рассказано с чего начать, если вы захотите внедрить инструмент статического анализа в уже существующий процесс разработки.
Реклама PVS-Studio - статический анализ кода на языке Си и Си++Andrey Karpov
Этот документ рекламирует статический анализатор PVS-Studio. Описывается, как использование PVS-Studio уменьшит количество ошибок в коде проекта на языке C/C++/C++11 и сократит затраты на тестирование, отладку и сопровождение кода. Приводится большое количество примеров ошибок, найденных анализатором в различных Open-Source проектах. Документ описывает PVS-Studio на момент версии 4.38 от 12 октября 2011 и, как следствие, не отражает возможности следующих версий. Чтобы познакомиться с новыми возможностями, предлагаем посетить сайт продукта <a>http://www.viva64.com</a> или поискать обновленный вариант этой статьи.
В статье описаны технологии тестирования, используемые при разработке статического анализатора кода PVS-Studio. Разработчики инструмента для программистов делятся принциами тестирования собственного программного продукта, которые могут быть интересны разработчикам аналогичных пакетов обработки текстовых данных или исходных кодов.
Регулярное использование статического анализа кода в командной разработкеTatyanazaxarova
Технологии статического анализа кода применяются в компаниях со зрелыми процессами разработки программного обеспечения. Однако уровень применения и внедрения в процесс разработки инструментов анализа кода может быть различным. Начиная от ручного запуска анализатора "время от времени" или при поиске трудноуловимых ошибок, и кончая ежедневным автоматическим запуском или запуском при добавлении нового исходного кода в систему контроля версий.
В статье рассмотрены различные уровни использования технологий статического анализа кода в командной разработке, показано как "перевести" процесс с одного уровня на другой. В качестве примера в статье используется разрабатываемый авторами анализатор кода PVS-Studio.
Статья рассказывает о новом направлении в развитии статических анализаторов кода - верификации параллельных программ. В статье рассказывается о нескольких статических анализаторах, которые могут претендовать на звание "Parallel Lint".
Выполняет анализ кода на языках: C, C++, C++/CLI, C++/CX, C#. Plugin для Visual Studio 2010-2015. Интеграция с SonarQube, QtCreator, CLion, Eclipse CDT, Anjuta DevStudio и т.д. Быстрый старт (мониторинг компиляции). Прямая интеграция анализатора в системы автоматизации сборки и утилита BlameNotifier (рассылка писем). Режим автоматического анализа изменённых файлов. Почему нужны анализаторы кода?
Программа для регрессионного тестирования анализаторов PVS-Studio, CppCatAndrey Karpov
Необходимо обеспечить регрессионное тестирование статических анализаторов кода PVS-Studio и CppCat.
Тесты должны выполняться на большом количестве открытых проектов, написанных на языке C/C++.
Должна тестироваться работа анализаторов в рамкам всех поддерживаемых версий Visual Studio.
Удобная работа со списком отличий, быстрый просмотр, возможность применить изменения и так далее.
Сравнение статического анализа общего назначения из Visual Studio 2010 и PVS-...Tatyanazaxarova
В статье показаны ошибки, выявленные с помощью статического анализатора кода, встроенного в Visual Studio 2010. Исследование проводилось на пяти open source проектах. Эти же проекты были проверены с помощью PVS-Studio. Приведены результаты сравнения этих двух инструментов.
Использование анализатора PVS-Studio в процессе инкрементальной сборки в Micr...Tatyanazaxarova
Одним из нововведений в последних версиях MSBuild/Visual Studio для компиляторов Visual C++ стала новая система минимальной сборки (также известная как инкрементная сборка), основанная на отслеживании зависимостей между входными и выходными данными при работе компилятора и позволяющая осуществлять пересборку только для файлов, затронутых модификацией исходного кода или не имеющих связанных с ними выходных объектных файлов. В отличие от старой методики минимальной пересборки, завязанной на генерируемые компилятором cl.exe файлы состояний (idb-файлы, Minimal Rebuild Dependancy Database, ключ /Gm) и обладавшей рядом недостатков (как например затруднённость распараллеливания сборки из-за конфликтов доступа и отсутствие прямого отслеживания выходных объектный файлов), новая система не зависит от типа используемых сборочных инструментов (может использоваться как для компиляции, так и для линковки) и имеет открытый API. Данная новинка позволила интегрировать проверку кода анализатором PVS-Studio в процесс разработки на C/C++ с использованием инкрементных пересборок для последней версии Visual Studio 2010. Эта возможность появилась в версии PVS-Studio 4.30.
SAST, борьба с потенциальными уязвимостямиAndrey Karpov
Доклад посвящен статическому анализу кода и ориентирован на тех, кто заинтересован в надёжности и безопасности разрабатываемого в компании программного кода. Условно можно выделить два направления статического тестирования защищённости приложений. Первый - это поиск уже известных уязвимостей методом сопоставления с шаблоном. Такой подход имеет право на существование и может обнаружить в вашем проекте код, взятый из старой библиотеки, подверженной определённой уязвимости. Второе направление - это выявление в новом коде участков кода, содержащих дефекты с точки зрения безопасности, то есть потенциальные уязвимости. Второе направление будет рассмотрено более подробно, а также будет рассказано что означают термины CWE, CVE и какая между ними связь. Дополнительно обсудим тему внедрения SAST в цикл разработки программного обеспечения, что может представлять интерес для DevSecOps специалистов.
Современный статический анализ кода: что умеет он, чего не умели линтерыcorehard_by
Статический анализ появился почти 40 лет назад. В своём докладе мы хотим показать, чему за это время научились статические анализаторы. Мы рассмотрим различные методики анализа, как они появлялись и какие ошибки можно найти с помощью них. Посмотрим на примеры ошибок, найденных PVS-Studio в Open Source проектах. Поговорим о том, чем статический анализатор отличается от "линтеров" и некоторых других инструментов, а также какие проблемы решает современный статический анализатор C++ кода, помимо собственно анализа кода.
Павел Беликов
@PVS-Studio, Тула, Россия
Поиск уязвимостей с использованием статического анализа кодаcorehard_by
Поиск уязвимостей с использованием статического анализа кода, Андрей Карпов и Евгений Рыжков
В последнее время мы все слышим о новых и новых уязвимостях, обнаруженных в программном обеспечении. Уже стало очевидно, что писать код без уязвимостей человечество не может. Но могут ли современные инструменты разработки помочь обнаружить хотя бы некоторые ошибки? В докладе НЕ будет фраз типа «купите такой-то инструмент, чтобы не допускать уязвимостей в своем и чужом коде». На реальных примерах мы попробуем показать какие типы уязвимостей или по-другому программных дефектов могут быть найдены с помощью технологий анализа кода, а какие – пока нет. Ну и конечно как писать код так, чтобы снизить вероятность появления уязвимостей в своем коде.
Поиск уязвимостей с использованием статического анализа кодаAndrey Karpov
Уязвимости - это те же самые обыкновенные ошибки. Зачем их выделять? Делайте это, если хотите заработать больше денег. CWE - Common Weakness Enumeration. CVE - Common Vulnerabilities and Exposures. Теперь с помощью Valgrind вы ищете не утечку памяти, а отказ в обслуживании!
Константин Книжник: статический анализ, взгляд со стороныTatyanazaxarova
Статья представляет интервью, взятое у Константина Книжника, сотрудником компании "Системы программной верификации" Андреем Карповым. Затронуты вопросы статического анализа кода, актуальность решений в этой области, а также перспективы использования статического анализа при разработке параллельных приложений.
Урок 25. Практическое знакомство с паттернами 64-битных ошибокTatyanazaxarova
Данная статья содержит различные примеры 64-битных ошибок, собранные в демонстрационном примере PortSample. Однако, начиная с версии PVS-Studio 3.63, вместо PortSample в дистрибутив PVS-Studio включается более новая версия примеров, которая называется OmniSample. Поэтому некоторые скриншоты в статье не соответствуют актуальному состоянию дел.
Многим читателя понравилась моя статья "Последствия использования технологии Copy-Paste при программировании на Си++ и как с этим быть" [1]. Обратил на неё внимание и Scott Meyers [2] и задал вопрос о том, как же собственно статический анализ помог выявить описанные в статье ошибки.
Я регулярно общаюсь с потенциальными пользователями, озабоченными ошибками в программах на языке Си++. Их озабоченность выражается в том, что они пробуют инструмент PVS-Studio и начинают писать о том, что при испытаниях что-то подозрительно мало ошибок было найдено. И хотя, вроде чувствуется, что инструмент им интересен, их реакция полна скептицизма.
PVS-Studio научился следить за тем, как вы программируетеTatyanazaxarova
В PVS-Studio появился режим работы, который поможет максимально рано выявлять ошибки и опечатки. Анализатор запускается сразу после компиляции файлов и если что-то не так, покраснеет от стыда за ваш код. Фича доступна на данный момент только для пользователей Visual Studio 2010.
Как создать качественный статический анализаторAndrey Karpov
В докладе я расскажу о методиках достижения высокого качества продукта, которые наша команда использует при разработке статического анализатора. Упор сделаю на особенности разработки, а также на повышение качества именно анализа, то есть поиска реальных ошибок и потенциальных уязвимостей в коде.
Similar to Трепещи, мир! Мы выпустили PVS-Studio 4.00 с бесплатным анализатором общего назначения (20)
Урок 27. Особенности создания инсталляторов для 64-битного окруженияTatyanazaxarova
При разработке 64-битной версии приложения дополнительное внимание стоит уделить и вопросу дистрибуции программы. Ведь при установке на 64-битной операционной системе есть несколько нюансов, забыв о которых можно получить неработающий инсталляционный пакет.
После компиляции программы в 64-битном режиме она начинает потреблять большее количество памяти, чем ее 32-битный вариант. Часто это увеличение почти незаметно, но иногда потребление памяти может возрастать в 2 раза.
Мы закончили рассмотрение паттернов 64-битных ошибок. Последнее на чем мы остановимся в связи с этими ошибками, является то, как они могут проявляться в программах.
Сам по себе рост размера структур не является ошибкой, но может приводить к потреблению необоснованного количества памяти и в результате к замедлению скорости работы программы. Будем рассматривать данный паттерн не как ошибку, но как причину неэффективности 64-битного кода.
Процессоры работают эффективнее, когда имеют дело с правильно выровненными данными. А некоторые процессоры вообще не умеют работать с не выровненными данными.
Генерирование и обработка исключений с участием целочисленных типов не является хорошей практикой программирования на языке Си++. Для этих целей следует использовать более информативные типы, например классы, производные от класса std::exception.
Урок 19. Паттерн 11. Сериализация и обмен даннымиTatyanazaxarova
Важным элементом переноса программного решения на новую платформу является преемственность к существующим протоколам обмена данными. Необходимо обеспечить чтение существующих форматов проектов, осуществлять обмен данными между 32-битными и 64-битными процессами и так далее.
Надеемся, вы уже успели отдохнуть от 13 урока и теперь сможете рассмотреть еще один важный паттерн ошибок, связанный с арифметическими выражениями, в которых участвуют типы различной размерности.
Урок 16. Паттерн 8. Memsize-типы в объединенияхTatyanazaxarova
Особенностью объединения (union) является то, что для всех элементов (членов) объединения выделяется одна и та же область памяти, то есть они перекрываются. Хотя доступ к этой области памяти возможен с использованием любого из элементов, элемент для этой цели должен выбираться так, чтобы полученный результат был осмысленным.
Большое количество ошибок при миграции на 64-битные системы связано с изменением соотношения между размером указателя и размером обычных целых. В среде с моделью данных ILP32 обычные целые и указатели имеют одинаковый размер. К сожалению, 32-битный код повсеместно опирается на это предположение. Указатели часто приводятся к int, unsigned, long, DWORD и другим неподходящим типам.
Мы специально выбрали номер "тринадцать" для этого урока, поскольку ошибки, связанные с адресной арифметикой в 64-битных системах, являются наиболее коварными. Надеемся, число 13 заставит вас быть внимательнее.
Урок 10. Паттерн 2. Функции с переменным количеством аргументовTatyanazaxarova
Классическими примерами, приводимыми во многих статьях по проблемам переноса программ на 64-битные системы, является некорректное использование функций printf, scanf и их разновидностей.
В некачественном коде часто встречаются магические числовые константы, наличие которых опасно само по себе. При миграции кода на 64-битную платформу эти константы могут сделать код неработоспособным, если участвуют в операциях вычисления адреса, размера объектов или в битовых операциях.
Исправление всех ошибок компиляции и предупреждений не будет означать работоспособность 64-битного приложения. И именно описанию и диагностике 64-битных ошибок будет посвящена основная часть уроков. Также не надейтесь на помощь ключа /Wp64, который многими часто без оснований преподносится при обсуждениях в форумах как чудесное средство поиска 64-битных ошибок.
Хочется сразу предупредить читателя, что невозможно всесторонне описать процесс сборки 64-битного приложения. Настройки любого проекта достаточно уникальны, поэтому к адаптации настроек для 64-битной системы всегда надо подходить внимательно. В уроке будут описаны только общие шаги, которые важны для любого проекта. Эти шаги подскажут вам с чего начать процесс.
Вначале следует убедиться, что используемая вами редакция Visual Studio позволяет собирать 64-битный код. Если вы планируете разрабатывать 64-битные приложения с использованием последней версии (на момент написания курса) Visual Studio 2008, то следующая таблица поможет определить, какая из редакций Visual Studio вам необходима.
Мы все допускаем ошибки при программировании и тратим массу времени на их устранение.
Один из методов который позволяет быстро диагностировать дефекты – статический анализ исходного кода.
PVS-Studio - статический анализатор, выявляющий ошибки в исходном коде приложений на языке C/C++/C++0x. Можно выделить 3 набора правил, включенных в состав PVS-Studio:
1. Диагностика 64-битных ошибок (Viva64)
2. Диагностика параллельных ошибок (VivaMP)
3. Диагностика общего назначения
Казалось, закончились долгие обсуждения в форумах, как измерить время работы алгоритма, какие функции использовать, какую точность ожидать. Жаль, но опять придется вернуться к этому вопросу. На повестке дня вопрос – как лучше измерить скорость работы параллельного алгоритма.
Трепещи, мир! Мы выпустили PVS-Studio 4.00 с бесплатным анализатором общего назначения
1. Трепещи, мир! Мы выпустили PVS-
Studio 4.00 с бесплатным
анализатором общего назначения
Автор: Андрей Карпов
Дата: 01.12.2010
Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде
приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил
общего назначения. Эта функциональность на данный момент является бесплатной.
Вы можете скачать PVS-Studio по адресу http://www.viva64.com/ru/pvs-studio-download/.
В статье кратко рассказывается о новых возможностях PVS-Studio. На примере статического
анализа исходного кода проекта TortoiseSVN будет продемонстрировано использование новых
диагностических возможностей.
PVS-Studio - современный анализатор исходного кода, интегрирующийся в среду Microsoft Visual
Studio 2005/2008/2010. Анализатор позволяет удобно работать со списком предупреждений и
использовать для своей работы несколько ядер процессора. PVS-Studio ориентирован на
разработчиков современных Windows-приложений на языке Си/Си++/Си++0x.
До настоящего момента в PVS-Studio входило два набора правил. Первый для выявления
дефектов в 64-битных программах. Второй для выявления дефектов в параллельных программах,
построенных на основе технологии OpenMP.
Теперь в анализаторе появился третий универсальный набор проверок, выявляющий
разнообразнейшие ошибки в коде. Данный набор правил является бесплатным и может быть
использован без каких-либо ограничений. Станет ли со временем этот набор платным или нет,
сейчас сказать сложно. В области анализа общего назначения мы только начинаем свой путь.
Сейчас вы можете познакомиться с новым набором правил, скачав PVS-Studio 4.00 BETA. Мы
будем рады получить от вас замечания по поводу замеченных ошибок и пожелания по
улучшению. Сразу хочу заметить, что для начала мы реализовали только 50 правил общего
2. назначения. Это немного. Поэтому если вы скачав и попробовав PVS-Studio сразу не найдете что
Studio что-
то интересное в своем коде, не торопитесь с выводами. Предлагаем вам в будуще вновь
будущем
попробовать PVS-Studio, когда набор проверок будет существенно увелич Мы планируем в
Studio, увеличен.
скором времени активно поработать над рас ирением базы диагностических правил (если хватит
тивно расширением
здоровья и повезет).
Продемонстрируем использование нового набора праправил PVS-Studio на примере TortoiseSVN.
TortoiseSVN –это клиент для системы контроля версий Subversion, выполненный как расширение
оболочки Windows. TortoiseSVN хорошо знаком многим разработчикам и думаю, подробнее
и,
описывать это приложение нет смысла. Отмечу только, что в 2007 году на SourceForge.net
TortoiseSVN был признан лучшим проектом в категории "инструменты и утилиты для
инструменты
разработчиков".
Шаг 1
Скачиваем PVS-Studio с сайта компании ООО "Системы программной верифик
Studio "Системы верификации" (это мы).
Надеюсь, вам будет приятно, что не надо заполнять никаких анкет или разгадывать капч Просто
капчу.
скачиваем.
Шаг 2
Устанавливаем PVS-Studio. Можно смело нажимать кнопку "Next". Настраивать ничего не надо.
Studio.
Дистрибутив PVS-Studio подписан цифровой подписью. Однако некоторые антивирусы все равно
Studio
могут насторожиться от действий, связанных с интеграцией в Visual Studio Всё разрешаем.
Studio.
Шаг 3
Скачиваем комплект исходных текстов проекта TortoiseSVN. Мы работали с исходным кодом
версии 1.6.11.
Шаг 4
Открываем проект TortoiseSVN и запускаем анализ. Для этого в меня PVS-Studio выберем команду
PVS-
Check Solution.
3. Шаг 5
Анализатор на некоторое время задумается (проект TortoiseSVN не так прост и содержит кучу
файлов). Поэтому не торопимся делать что то в этот момент и немного подождем. Через
). что-то
некоторое время появится диалог прогресса и начнется анализ. Скорость анализа зависит от
количества ядер в процессоре. Если PVS
PVS-Studio будет съедать слишком много ресурсов, можно в
настройках ограничить его желания.
Сообщения анализатор выдает в свое собственное окошко, где имеются элементы управления для
включения/выключения различных типов сообщений. И мы воспользуемся этими возможностями.
Сейчас совершенно не интересно смотреть на множество ошибок связанных с 64 64-битностью. Тем
более что 64-битный анализ платен, и поэтому ограничен (подробнее про trial-режим смотрите
битный подробнее
здесь).
В окне виден набор из трех кнопок, отвечающий за вывод сообщений из трех наборов правил.
1) 64 - диагностические сообщения о 64-битных дефектах (Viva64);
иагностические
2) MP - диагностические сообщения о параллельных дефект (VivaMP);
дефектах
3) GA - диагностические сообщения общего типа (General Analysis).
Нам интересен только набор правил общего назначения (GA). Отжимаем другие кнопки и
тжимаем кнопки,
лишние сообщения в списке будут тут же спрятаны.
Ждем завершения анализа.
Шаг 6
Анализ закончен, и мы видим список всех мест в программе, для которых анализатор
идим
рекомендует сделать обзор кода (
(code review).
4. Все предупреждения разделены на 3 уровня важности (это новое в PVS-Studio 4.00). Обычно,
имеет смысл смотреть только первый и второй уровень. PVS-Studio 4.00 BETA выдала 33
предупреждения первого уровня, 14 предупреждений второго уровня и 8 предупреждений
третьего уровня.
Стоит начать знакомство с предупреждений первого уровня. Поэтому можно отключить кнопку,
обозначающую вывод сообщений второго уровня. Третий уровень по умолчанию уже отключен.
Шаг 7
Рассмотрим интересные места в коде, обнаруженные анализатором.
Ситуация 1
В самом начале сразу два сообщения относятся к одной функции. Хочется надеяться, что эта
функция особенно нигде не используется.
V530 The return value of function 'empty' is required to be utilized. contextmenu.cpp 434
V530 The return value of function 'remove' is required to be utilized. contextmenu.cpp 442
STDMETHODIMP CShellExt::Initialize(....)
{
...
ignoredprops.empty();
for (int p=0; p<props.GetCount(); ++p)
{
if (props.GetItemName(p).
compare(SVN_PROP_IGNORE)==0)
{
std::string st = props.GetItemValue(p);
ignoredprops = UTF8ToWide(st.c_str());
// remove all escape chars ('')
std::remove(ignoredprops.begin(),
ignoredprops.end(), '');
5. break;
}
}
...
}
Здесь и далее будет даваться только краткий комментарий к фрагментам кода. Подробнее,
узнать, почему код считается подозрительным, вы можете в online-документации к PVS-Studio
(она доступна на русском и английском языке). Также в комплекте с PVS-Studio идет документация
(та же самая) в формате PDF-файла. Далее будут даваться ссылки на соответствующие описания
диагностических сообщений.
Предупреждение V530 подсказывает нам, что "ignoredprops.empty()" вовсе не очищает строку, а
"std::remove()" на самом деле не удалит символы.
Ситуация 2
Здесь происходит проверка, что переменная типа 'char' больше или равна значению 0x80.
V547 Expression 'c >= 0x80' is always false. The value range of signed char type: [-128, 127].
pathutils.cpp 559
CString CPathUtils::PathUnescape (const char* path)
{
// try quick path
size_t i = 0;
for (; char c = path[i]; ++i)
if ((c >= 0x80) || (c == '%'))
{
// quick path does not work for
// non-latin or escaped chars
std::string utf8Path (path);
CPathUtils::Unescape (&utf8Path[0]);
return CUnicodeUtils::UTF8ToUTF16 (utf8Path);
}
...
}
6. Сообщение V547 уведомляет, что такая проверка бессмысленна. Значение типа 'char' всегда будет
меньше 0x80, а значит условие всегда ложно. И возможно именно из-за этой ошибки в коде
написан комментарий "quick path does not work for non-latin or escaped chars". Конечно не
работает, но не потому что не получается конвертировать строку. Когда попадается non-latin
символ, мы просто не заходим в тело оператора 'if'.
Ситуация 3
Множество потоков создается и убивается с помощью функций CreateThread/ExitThread. А,
следовательно, мы рискуем быстро исчерпать стек потока или не освободить часть ресурсов,
когда поток завершается. Подробнее читайте в описании предупреждения V513. Намного
безопаснее использовать функции _beginthreadex() и _endthreadex().
Пример кода приводить здесь смысла нет, а текст всех сообщений одинаков:
V513 Use _beginthreadex/_endthreadex functions instead of CreateThread/ExitThread functions.
crashhandler.cpp 379
Ситуация 4
Это относится к сопутствующим TortoiseSVN утилитам. Очень вероятно, что при работе с CrashLog
все закончится другим Crash.
V510 The 'printf_s' function is not expected to receive class-type variable as fourth actual argument.
excprpt.cpp 199
string CExceptionReport::getCrashLog()
{
...
_tprintf_s(buf, _T("%s%s.xml"),
getenv("TEMP"), CUtility::getAppName());
...
}
Сообщение V510 предупреждает, что передавать в функцию printf_s параметр типа std::string
очень плохо. А функция CUtility::getAppName() возвращает именно std::string. Ошибка в том, что
забыли написать ".c_str()". Последствием может быть как просто некорректный вывод данных, так
и падение программы.
Ситуация 5
Хотели очистить массив, но не смогли.
V530 The return value of function 'empty' is required to be utilized. mailmsg.cpp 40
CMailMsg& CMailMsg::SetFrom(string sAddress,
string sName)
7. {
if (initIfNeeded())
{
// only one sender allowed
if (m_from.size())
m_from.empty();
m_from.push_back(TStrStrPair(sAddress,sName));
}
return *this;
}
Вновь сообщение V530 подсказывает, что вместо "clear()" случайно написано "empty()".
Ситуация 6
И в функции SetTo() тоже не смогли очистить массив.
V530 The return value of function 'empty' is required to be utilized. mailmsg.cpp 54
CMailMsg& CMailMsg::SetTo(string sAddress,
string sName)
{
if (initIfNeeded())
{
// only one recipient allowed
if (m_to.size())
m_to.empty();
m_to.push_back(TStrStrPair(sAddress,sName));
}
return *this;
}
Ситуация 7
8. Есть, конечно, и ложные срабатывания. Вот, например, фрагмент кода из библиотеки zlib,
включенной в проект TortoiseSVN. Ошибки здесь нет, но отметить такое место сообщением V501
очень полезно.
V501 There are identical sub-expressions to the left and to the right of the '-' operator: size - size zutil.c
213
voidpf zcalloc (opaque, items, size)
voidpf opaque;
unsigned items;
unsigned size;
{
/* make compiler happy */
if (opaque) items += size - size;
return (voidpf)calloc(items, size);
}
Компилятор конечно здесь счастлив, но вычитание выглядит подозрительно.
Ситуация 8
С кодировками есть и другие тёмные места. Вот еще одно условие, которое всегда ложно.
V547 Expression '* utf8CheckBuf >= 0xF5' is always false. The value range of signed char type: [-128,
127]. tortoiseblame.cpp 312
BOOL TortoiseBlame::OpenFile(const TCHAR *fileName)
{
...
// check each line for illegal utf8 sequences.
// If one is found, we treat
// the file as ASCII, otherwise we assume
// an UTF8 file.
char * utf8CheckBuf = lineptr;
while ((bUTF8)&&(*utf8CheckBuf))
{
if ((*utf8CheckBuf == 0xC0)||
(*utf8CheckBuf == 0xC1)||
9. (*utf8CheckBuf >= 0xF5))
{
bUTF8 = false;
break;
}
...
}
Кстати, условия "*utf8CheckBuf == 0xC0", "*utf8CheckBuf == 0xC1" тоже всегда ложны. Поэтому код
"bUTF8 = false;" никогда не получит управление. То, что анализатор PVS-Studio не стал ругать
выражение "*utf8CheckBuf == 0xC0" является недоработкой. Записали в список улучшений. В
следующей версии будем ругаться и на это.
Ситуация 9
Со следующим сообщением не все так просто. Теоретически в коде имеется ошибка. Практически
- этот код работает.
V507 Pointer to local array 'stringbuf' is stored outside the scope of this array. Such a pointer will
become invalid. mainwindow.cpp 277
LRESULT CALLBACK CMainWindow::WinMsgHandler(....)
{
...
if (pNMHDR->code == TTN_GETDISPINFO)
{
LPTOOLTIPTEXT lpttt;
lpttt = (LPTOOLTIPTEXT) lParam;
lpttt->hinst = hResource;
// Specify the resource identifier of the
// descriptive text for the given button.
TCHAR stringbuf[MAX_PATH] = {0};
...
lpttt->lpszText = stringbuf;
10. }
...
}
Диагностическое сообщение V507 предупреждает, что объект используется уже после окончания
своего существования. Буфер 'stringbuf' будет использоваться уже после выхода из тела оператора
'if'.
Если бы 'stringbuf' был бы объектом класса, например std::string, то данный код вел бы себя
некорректно. Мы бы использовали уже разрушенный объект. Но здесь 'stringbuf' является
массивом, созданным в стеке. Компилятор Visual C++ повторно не использует данный участок
стека, и буфер будет существовать до конца работы функции 'CMainWindow::WinMsgHandler'.
Таким образом, никакой ошибки не возникнет, хотя код потенциально опасен.
Ситуация 10
И еще одно такое же место, как и в примере выше. Вновь это код, который работает, но хрупок.
V507 Pointer to local array 'stringbuf' is stored outside the scope of this array. Such a pointer will
become invalid. picwindow.cpp 443
if ((HWND)wParam == m_AlphaSlider.GetWindow())
{
LPTOOLTIPTEXT lpttt;
lpttt = (LPTOOLTIPTEXT) lParam;
lpttt->hinst = hResource;
TCHAR stringbuf[MAX_PATH] = {0};
_stprintf_s(stringbuf, .....);
lpttt->lpszText = stringbuf;
}
Ситуация 11
Плохая идея бросать и не обрабатывать в деструкторе исключения.
V509 The 'throw' operator inside the destructor should be placed within the try..catch block. Raising
exception inside the destructor is illegal. cachefileoutbuffer.cpp 52
CCacheFileOutBuffer::~CCacheFileOutBuffer()
{
if (IsOpen())
11. {
streamOffsets.push_back (GetFileSize());
size_t lastOffset = streamOffsets[0];
for (size_t i = 1,
count = streamOffsets.size();
i < count; ++i)
{
size_t offset = streamOffsets[i];
size_t size = offset - lastOffset;
if (size >= (DWORD)(-1))
throw CStreamException("stream too large");
Add ((DWORD)size);
lastOffset = offset;
}
Add ((DWORD)(streamOffsets.size()-1));
}
}
Сообщение V509 предупреждает, что если объект CCacheFileOutBuffer разрушается в процессе
обработки исключения, то новое исключение приведет к немедленному аварийному завершению
программы.
Ситуация 12
Очередное сравнение, которое не имеет смысла.
V547 Expression 'endRevision < 0' is always false. Unsigned type value is never < 0. cachelogquery.cpp
999
typedef index_t revision_t;
...
void CCacheLogQuery::InternalLog (
revision_t startRevision
12. , revision_t endRevision
, const CDictionaryBasedTempPath& startPath
, int limit
, const CLogOptions& options)
{
...
// we cannot receive logs for rev < 0
if (endRevision < 0)
endRevision = 0;
...
}
Отрицательных значений здесь просто не может быть. Переменная endRevision имеет
беззнаковый тип, а, следовательно, всегда endRevision >= 0. Потенциальная беда состоит в том,
что если где-то раньше отрицательное значение превратилось в беззнаковый тип, то мы начнем
работать с очень большим числом. Для этого ведь проверки нет.
Ситуация 13
Больше полезных сообщений первого уровня нет. Пока нет. Ведь это только первая проба пера
новых возможностей PVS-Studio. У нас записано в план развития не менее 150 примеров, которые
стоит научиться выявлять. Еще раз спасибо читателям, кто откликнулись на предыдущие статьи и
присылали примеры, в которых можно выявить ошибки статическим анализом на этапе написания
кода.
Заглянем на второй уровень. Мы обнаружим одну интересную ошибку, связанную с
использованием методики Copy-Paste. Кстати, на третьем уровне не оказалось вообще ничего
интересного, так что не зря мы его по умолчанию отключаем.
V524 It is odd that the 'GetDbgHelpVersion' function is fully equivalent to the 'GetImageHlpVersion'
function (SymbolEngine.h, line 98). symbolengine.h 105
BOOL GetImageHlpVersion(DWORD &dwMS, DWORD &dwLS)
{
return(GetInMemoryFileVersion(("DBGHELP.DLL"),
dwMS,
dwLS)) ;
}
13. BOOL GetDbgHelpVersion(DWORD &dwMS, DWORD &dwLS)
{
return(GetInMemoryFileVersion(("DBGHELP.DLL"),
dwMS,
dwLS)) ;
}
Сообщение V524 выдается в том случае, если обнаруживаются две подозрительные одинаковые
функции. Скорее всего, первая функция должна получать версию файла "imagehlp.dll", а вовсе не
"dbghelp.dll ".
Шаг 8
Сейчас найденные ошибки должны быть исправлены. Данный этап понятен и мы его пропустим.
Что касается найденных ошибок, то мы сообщим о них разработчикам TortoiseSVN.
Шаг 9
Теперь поговорим немного о ложных срабатываниях. Приведем некоторые примеры, чтобы
пояснить, что такое ложное срабатывание и как с ними можно поступить.
Первое ложное срабатывание. PVS-Studio не разобрался в играх с копированием памяти.
V512 A call of the 'memcpy' function will lead to a buffer overflow or underflow. resmodule.cpp 838
const WORD*
CResModule::CountMemReplaceMenuExResource(....)
{
...
if (newMenu != NULL) {
CopyMemory(&newMenu[*wordcount], p0, 7 * sizeof(WORD));
}
...
}
Предупреждение V512 должно указывать на то, что буфер обработан не полностью или что
наоборот мы вышли за его пределы. Сейчас анализатор ошибся, решив, что мы будем работать
только с одним объектом типа WORD, а скопировать хотим 7 объектов.
Второе ложное срабатывание. Здесь анализатор считает, что обработали только часть массива.
14. V512 A call of the 'memcmp' function will lead to a buffer overflow or underflow. sshsha.c 317
static int sha1_96_verify(....)
{
unsigned char correct[20];
sha1_do_hmac(handle, blk, len, seq, correct);
return !memcmp(correct, blk + len, 12);
}
Действительно сравнивается только часть массива 'correct', но так и было задумано.
Третий пример ложного срабатывания.
V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error
presence. tree234.c 195
static void *add234_internal(....)
{
...
if ((c = t->cmp(e, n->elems[0])) < 0)
childnum = 0;
else if (c == 0)
return n->elems[0]; /* already exists */
else if (n->elems[1] == NULL
|| (c = t->cmp(e, n->elems[1])) < 0)
childnum = 1;
else if (c == 0)
return n->elems[1]; /* already exists */
else if (n->elems[2] == NULL
|| (c = t->cmp(e, n->elems[2])) < 0)
childnum = 2;
else if (c == 0)
return n->elems[2]; /* already exists */
else
childnum = 3;
15. ...
}
Анализатору не нравится, что несколько раз присутствует проверка 'c == 0'. Код корректен, так как
переменная 'c' меняется внутри других условий "c = t->cmp(e, n->elems[2])". Однако это достаточно
редкая ситуация. Чаще сообщение V517 указывает на настоящие дефекты в коде.
Остальные ложные срабатывания рассматриваться не будут, так как они не интересны.
Программисту достаточно легко понять, что они ложные и не стоит уделять им много внимания.
Поступать с ложными срабатываниями можно по-разному:
1) Можно переписать код. Иногда это вполне разумно. Последнему примеру с ложным
срабатыванием рефакторинг вовсе не повредит (речь идет про функцию add234_internal и
предупреждение V517).
2) Можно отключить в настройках некоторые проверки, которые в ваших проектах всегда дают
ложное срабатывание. После отключения, из таблицы сразу исчезнут все эти сообщения.
Подробнее здесь: "Settings: Detectable Errors".
3) Если ложные срабатывания относятся к коду, которые не стоит проверять, то можно исключить
отдельные файлы или папки. Можно использовать маски. Подробнее здесь "Settings: Don't Check
Files". Это удобно, чтобы исключать из анализа сторонние библиотеки.
4) Можно использовать механизм подавления сообщений, содержащих определенный текст.
Подробнее здесь: "Settings: Message Suppression".
5) Есть ситуации, когда следует подавить конкретное предупреждение. В этом случае можно
использовать функцию "Mark as False Alarm" ("Пометить как ложное срабатывание"). В этом
случае в код вставляется маленький комментарий вида: "//-Vкод_ошибки". Размеченные таким
образом участки кода могут быть скрыты в списке ошибок. Для этого служит кнопка FA,
включающая/выключающая показ помеченных сообщений. Подробнее здесь: "Подавление
ложных предупреждений".
Всем спасибо за внимание. Пробуйте PVS-Studio. Присылайте свои отзывы. Задавайте вопросы.
Покажите примеры, если у вас найдется что-то интересное. Предлагайте новые диагностические
правила для реализации.
С уважением, Андрей Карпов, один из разработчиков PVS-Studio.
Вы можете связаться с нами с помощью страницы "Обратная связь".
Или по E-mail: support[@]viva64.com , karpov[@]viva64.com.
Пишите нам, у нас замечательная поддержка. Я лично, автор статьи, приму участие в общении, а
не абстрактный человек-робот, как бывает в большинстве компаний.