Comments 34
Вы не могли бы связаться с разработчикам хорошо пропиариной на хабре PVS-studio и попросить у них прогнать эти же тесты?) Было бы интересно посмотреть действительно ли коммерческие аналоги лучше)
Отличная идея! Если не ошибаюсь у них есть триальная версия, тогда мне самому нужно будет тесты гонять)
Полтора месяца назад PVS не находил ни разыменования нулевых указателей, ни утечек памяти, ни непарных new[]-delete[], тогда как CppCheck с этим успешно справлялся (тема на rsdn).
Впрочем, не удивлюсь, если сейчас разработчики PVS-Studio быстро добавят фильтр на вышеприведённые куски кода и через пару дней выступят с разгромной статьёй =)
Впрочем, не удивлюсь, если сейчас разработчики PVS-Studio быстро добавят фильтр на вышеприведённые куски кода и через пару дней выступят с разгромной статьёй =)
С++…
«Сферический анализатор результатов анализа утилит статического анализа кода позитронного анализатора»…
А как так получилось, что у вас GCC не ругается на неиспользованный результат fopen? Может это вообще не от компилятора зависит?
www.ideone.com/eBflq
warning: ignoring return value of ‘FILE* fopen(const char*, const char*)’, declared with attribute warn_unused_resultwww.ideone.com/eBflq
Интересно, и правда не ругается, «копну поглубже».
Это зависит от заголовочных файлов: объявлена ли функция с атрибутом warn_unused_result или нет. Можете этот атрибут даже к своим функциям применять и GCC будет ругаться.
Это-то понятно. Вопрос в том, почему эти атрибуты отсутствуют в заголовочных файлах стандартной библиотеки той же Ubuntu. Это же больше сотни функций (вот примерный список). Под подозрением eglibc, облегчённая версия glibc, которая используется в Ubuntu. В настоящей glibc __wur присутствует с 2006 года и никто его не трогал [1].
В Debian Unstable eglibc 2.13 и __wur для fopen() есть.
Ха-ха, Ubuntu прекрасна в своём роде. Уже собрался идти в багзиллу жаловаться на потерянные __wur, но тут наткнулся на wiki.ubuntu.com/CompilerFlags#A-D_FORTIFY_SOURCE.3D2
Таким образом, за проверку использования возвращаемых значений отвечает флаг оптимизации -O2, с чем я не могу поспорить.
Таким образом, за проверку использования возвращаемых значений отвечает флаг оптимизации -O2, с чем я не могу поспорить.
Добавте С++ в заголовок, пожалуйста, а не в теги.
Apple clang version 3.0 (tags/Apple/clang-211.9)
clang++ --analyze
1. ничего
2. ничего
3.
4.
clang++ --analyze
1. ничего
2. ничего
3.
test.cpp:11:5: warning: Undefined or garbage value returned to caller
return a;4.
test.cpp:14:5: warning: Undefined or garbage value returned to caller
return a;
sprintf(buf, "%4d", i);а здесь где баг?
4 символа + завершающий ноль влазят в 5символьный буфер, не?
Если уж включать в этот список GCC, то стоит к его ключам добавить -Wextra и -pedantic.
>> В том, что мне нужна утилита, которая подскажет, что в случае v.reserve(2); v[0] = 1; лучше использовать v.resize(2); v[0] = 1; или v.reserve(2); v.push_back(1)! А рассмотренные нами утилиты мило промолчали. Еще мне нужна утилита, проверяющая неправеренные границы, и в случае v[0]; посоветовать использовать v.at(0).
Полагаю, что по этим диагностикам количество false positive будет зашкаливающим. Поэтому и не делают. То есть это скорее всего диагностика, которая будет делаться под заказ для конкретного заказчика, которому она нужна.
Полагаю, что по этим диагностикам количество false positive будет зашкаливающим. Поэтому и не делают. То есть это скорее всего диагностика, которая будет делаться под заказ для конкретного заказчика, которому она нужна.
Также надо понимать, что скриптовый graudit не является полноценным инструментом статического анализа кода по причинам, изложенным в статье Статический анализ и регулярные выражения.
а какая версия g++ использовалась?
Я считаю, что все статические анализаторы для C++ просто бесполезная трата времени и иллюзия качества кода. Было есть и будет, что качество C++ кода определяется образованием, опытом, талантом разработчика. Эти примеры — ни о чем не говорят, они надуманы. Более того реальные C++ проблемы вообще даже человеку отследить трудно статически. И прежде всего, виновато в этом ручное управление временем жизни объектов — кто-то использует указатель на объект, его грохают в другом месте, в первом обращаются и привет. Overflow неплохо отлавливают сейчас — buffer security check, проверка при free (это про Visual С++), а еще инструменты как Microsoft Application Verifier. Проблема в том, что для статического определения корректности надо знать СЕМАНИТКУ метода, а определение этого в общем случае в C++ невозможно.
Немного модифицирую текст:
Я считаю, что все инструменты проверки орфографии для русского языка просто бесполезная трата времени и иллюзия качества текста. Было есть и будет, что качество текста определяется образованием, опытом, талантом автора. Эти примеры с ошибками — ни о чем не говорят, они надуманы.
И вроде всё правильно написано. Но только оторвано от практики. Проверка орфографии в Word не призвана заменить преподавание русского языка в школе. Статически анализ не призван отменить вдумчивое программирование. Но это инструменты, которые могут помочь. Вы думаете, когда Пелевин или Лукьяненко работает над книгой, они ошибки и опечатки в тексте не делают? Взяв первого попавшегося дворника, сложно ожидать от него получить роман. И тут проверка орфографии вообще мимо. Но если проверка орфографии помогает мастеру создать роман с меньшим количеством вычитываний текста – это замечательно.
Я считаю, что все инструменты проверки орфографии для русского языка просто бесполезная трата времени и иллюзия качества текста. Было есть и будет, что качество текста определяется образованием, опытом, талантом автора. Эти примеры с ошибками — ни о чем не говорят, они надуманы.
И вроде всё правильно написано. Но только оторвано от практики. Проверка орфографии в Word не призвана заменить преподавание русского языка в школе. Статически анализ не призван отменить вдумчивое программирование. Но это инструменты, которые могут помочь. Вы думаете, когда Пелевин или Лукьяненко работает над книгой, они ошибки и опечатки в тексте не делают? Взяв первого попавшегося дворника, сложно ожидать от него получить роман. И тут проверка орфографии вообще мимо. Но если проверка орфографии помогает мастеру создать роман с меньшим количеством вычитываний текста – это замечательно.
Неверная аналогия. В корне. ОРФОГРАФИЮ проверяет компилятор. А вот статический анализатор пытается проверить СМЫСЛ (семантику текста). То есть как бы все по правилам написано, но смысла нет или предложение не верно. Ведь предложение «Я вижу летучего зайца» безупречно орфографически и построено по правилам, но лишено смысла.
Проверить орфографию — не проблема. А проверить осмысленность кода (верифицировать) что вы пытаетесь делать в своей PVS — невыполнимая задача. Нужно сначала иметь язык, верификация которого будет проще на порядки чем в C++.
Я вам могу привести осмысленный код, который PVS считает неверным.
Проверить орфографию — не проблема. А проверить осмысленность кода (верифицировать) что вы пытаетесь делать в своей PVS — невыполнимая задача. Нужно сначала иметь язык, верификация которого будет проще на порядки чем в C++.
Я вам могу привести осмысленный код, который PVS считает неверным.
Не то, чтоб задача невыполнима, а то, что сложна, и от этого не следует, что такой утилиты не следует выпускать. Лично я хочу и считаю нужным использовать статический анализатор. Во-первых, насколько бы код не был хорош, всегда появляются ошибки из-за невнимательности. Во-вторых, статический анализатор — это как бы коллега-ревьюер, на всякий случай проверяет ваш код.
Вы делаете хорошую работу. Любой инструмент, увеличивающий вероятность отловить дурные ошибки, нужен и полезен.
Я вижу смысл делать тул, который по функции, анализируя ее, будет пытаться выдавать набор Unit Test-ов и тестовых данных для него, пытаясь скажем, сделать максимальным покрытие ветвлений и проверять то что ей кажется странным набором тестов.
Более сложный вариант — как препроцессор, который бы как-то модифицировал код, объектник или что-то еще, вставляя проверки в разные подозрительные места. Это как автоматические ассерты.
Более сложный вариант — как препроцессор, который бы как-то модифицировал код, объектник или что-то еще, вставляя проверки в разные подозрительные места. Это как автоматические ассерты.
KLEE?
Sign up to leave a comment.
Анализ утилит статического анализа C++ кода