Если честно, не понятна о какой ситуации идёт речь. Есть подозрение, что с кодом всё-таки что-то не так. Прошу привести конкретный синтетический пример, на котором выдаётся ложное срабатывание, и мы обсудим его.
Если честно, не понятна о какой ситуации идёт речь. Есть подозрение, что с кодом всё-таки что-то не так. Прошу привести конкретный синтетический пример, на котором выдаётся ложное срабатывание, и мы обсудим его.
Мне кажется, Вы путаетесь. То, что мы ищем, и есть дефект безопасности (CWE). Ошибка в коде (дефект) может стать причиной уязвимости. Поэтому есть смысл писать «потенциальная уязвимость», что мы и делаем.
Но нет смысла писать «потенциальны дефект» (какой-же он потенциальный, когда вот она ошибка!).
Гм… Казалось бы, мы и не путаем CWE и CVE и как раз я вчера про это рассуждал в статье "PVS-Studio: поиск дефектов безопасности". И я везде и пишу о потенциальных уязвимостях (они-же дефекты безопасности, т.е. CWE).
Что касается перечисленных вами проблем, то мы их ищем, что не раз демонстрировалось в различных статьях.
Данные ошибки ещё не подтвержденные уязвимости (CVE), а только потенциальные уязвимости. Можно их использовать или нет — это сложная исследовательская задача, интересная не нам пользователям, а злоумышленникам. Нам же пользователям/разработчикам интересно побыстрее исправить эти ошибки от греха подальше.
Про проверки. Да, где-то их может не хватать. Но, например, всё перечисленное здесь возникло не из-за отсутствия проверок, а из-за ошибок в коде.
Что нужно делать? Это целый комплекс мер, который тянет на книгу. Но точно могу сказать, одна из мер, это использование статических анализаторов кода, таких как PVS-Studio. :)
вот когда предупреждает про одинаковое тело просто метода и const метода — огорчает. Может стоит дополнить правило, что если у методов одинаковые имена и списки аргументов, но различный const у возвращаемого значения и самого метода, то для них не предупреждать об одинаковом теле?
Если я всё правильно понял, то такого срабатывания быть не должно. Прошу привести синтетический пример, на котором воспроизводится ложное срабатывание. Можно в почту.
Всё равно так делать НЕЛЬЗЯ. Например, перед массивом может храниться его размер. И не важно, что для int[] это не обязательно. Да и вообще нет смысла рассуждать. Это UB. Точка.
Ды фигня тут получилась, бывает. Перефразируя поговорку, не ошибается в статьях только то, кто их не пишет. :)
Мы столько кода и багов перелопачиваем, что сложно сосредоточиться.
Но нет смысла писать «потенциальны дефект» (какой-же он потенциальный, когда вот она ошибка!).
Что касается перечисленных вами проблем, то мы их ищем, что не раз демонстрировалось в различных статьях.
В целом же ничего удивительно. Задача PVS-Studio в том и состоит, чтобы быть лучше компиляторов в плане поиска дефектов.
Такие предупреждения уже есть, хотя их пока немного. Мы называем их микро-оптимизации.
Про проверки. Да, где-то их может не хватать. Но, например, всё перечисленное здесь возникло не из-за отсутствия проверок, а из-за ошибок в коде.
Что нужно делать? Это целый комплекс мер, который тянет на книгу. Но точно могу сказать, одна из мер, это использование статических анализаторов кода, таких как PVS-Studio. :)
Ещё примеры поиска уязвимостей в коде FreeBSD:
Мы столько кода и багов перелопачиваем, что сложно сосредоточиться.