Тонкости анализа исходного кода C/C++ с помощью cppcheck

[@HgeN]

Вот в чем неимоверный плюс открытых анализаторов, так это в том, что можно писать кастомные правила.
Некоторые небезызвестные проприетарные анализаторы, насколько мне известно, этого не умеют.

[@Andrey2008]

Если Вы про PVS-Studio, то это и не нужно. Вы приобретаете лицензию (т.е. инструмент и поддержку). Мы реализуем то, чего не хватает. У нес нет пользователей, которые бы хотели непременно сделать диагностическое правило сами. Всем нравится, как мы реализовываем необходимое им. У нас идеальный интерфейс для написания правил.

[@ploop]

Можно вопрос?
Вот прогнал сейчас проект (Qt, опция --library=qt), ошибок нет (разве что забыл инициализировать одну переменную). Так как проект относительно немаленький, а опыта у меня нет практически — то вряд ли такое возможно :)
Начинаю проверять, добавляю где-то: int *error = new int; — находит, но тут и ежу понятно. Но MyObject *obj = new MyObject() уже не видит. Запускаю с опцией --check-config — точно, не видит библиотек.

Собственно, как его заставить корректно работать с Qt-библиотеками? Так как в коде много объектов создаётся/уничтожается в процессе работы, не хотелось бы допустить где-нибудь утечек…

[@RPG]

Интересно. new Type[10] ловит, а просто new Type — уж не ловит. Возможно это либо баг, либо перестраховка. Но всё что не нашёл cppcheck можно найти с помощью valgrind:)

К Qt как таковому это не относится.

[@ploop]

valgrind'ом пользуюсь (вроде нормально, да и IDE поддерживает его), а вот статические анализаторы ни разу не пробовал :)

[@RPG]

Если уж valgrind ничего не нашёл — возможно в коде действительно нет утечек:)

P.S. Я нашёл, что определяет поведение cppcheck в таком случае. Он просто не проверяет утечки для классов. Возможно это связано с деструкторами или частыми ложными срабатываниями, но можете попробовать: файл checkmemoryleak.cpp, строка 879, здесь даже есть комментарий:

                // don't check classes..
                if (alloc == CheckMemoryLeak::New) {
                    if (Token::Match(tok->tokAt(2), "new struct| %type% [(;]")) {
...

Если этот блок if убрать — он не будет пропускать инициализированные классы. Можете попробовать на своём проекте, результат может быть двояким — либо найдёте кучу ошибок, либо кучу ложных срабатываний.

В Git Blame по этому поводу ничего подозрительного, может быть, данный патч был не для утечек, а для предупреждений, но в результате повлиял на поиск утечек. Раньше эта проверка включалась флагом inconclusive…

[@DmitryMe]

Если уж valgrind ничего не нашёл — возможно в коде действительно нет утечек:)

На самом деле, можно расчитывать только на то, что утечек не было при этом конкретном запуске. Запросто могут быть варианты выполнения программы, которые в этом запуске не были пройдены, но которые привели бы к утечке. В этом существенная разница между программами вроде valgring и статическими анализаторами. Статический анализатор может просто посмотреть на код и увидеть в нем ошибку даже если этот код никогда не вызывается.

[@RPG]

Как раз такими типичными вариантами работы программы являются обработчики ошибок — поставили return между alloc/dealloc — и встречайте. В реальной жизни этот код может никогда и не выполнится, а cppcheck эти ошибки частенько вскрывает.

[@RPG]

Ваш комментарий натолкнул действительно на интересную проблему. Я сейчас отключил в исходниках тот блок анализатора, который отвечал за блокировку классов, и повторил анализ недавнего npp (у меня мало что плюсового находится под рукой).

Действительно, нашёл как минимум одну утечку памяти, которую я пропустил в предыдущем анализе:

bool ProjectPanel::openWorkSpace(const TCHAR *projectFileName)
{
	TiXmlDocument *pXmlDocProject = new TiXmlDocument(projectFileName);
	bool loadOkay = pXmlDocProject->LoadFile();
	if (!loadOkay)
		return false;
...
	delete pXmlDocProject;
	return loadOkay;
}

В ближайшее время попробую обсудить это с разработчиками cppcheck. На мой взгляд тот блок кода надо обернуть в inconclusive.

[@ploop]

Тоже пересобрал без этого блока. И таки да, одно ложное он дал, не знает метод deleteLater() наследников QObject. Если поставить жесткий delete, тогда не ругается.

Вообще очень удобный инструмент, буду пользоваться.

[@Andrey2008]

Меня радуют, что появляются такие статьи. Неужто наконец в России начала зарождаться культура использования инструментов статического анализа. И ещё приятно, что мы дали «первопинок» этому направлению у нас. Ну по крайней мере, на Хабре точно. :)

[@Next_Alex]

Не стоит переоценивать свой вклад.
Использовали до вас и независимо от вас.

[@Biga]

Попробую тоже задать свой вопрос, вдруг кто-нибудь ответит.

Существует ли какой-нибудь способ использовать cppcheck в связке с XCode?

Сейчас мне приходится конфигурировать cppcheck, копируя в него настройки из XCode, и всё равно cppcheck жалуется на отсутствие некоторых дефайнов, связанных с определением платформы.

К примеру, есть достаточно большой проект в XCode на C++. В настройках проекта определены все нужные #define'ы, поэтому нет никакой надобности, чтобы cppcheck их перебирал. Определены все библиотеки, пути до заголовков, параметры компиляции. XCode мог бы даже сделать правильное препроцессирование (используя clang), если это могло бы хоть что-то дать.
Можно ли как-то подружить его с cppcheck?

[@Biga]

Analyze тоже полезен, но cppcheck другие ошибки находит.

[@aabzel]

Господа, существует ли утилита для проверки в коде C того, что порядок объявления функций соответствует порядку определения функций?