RPG Jan 31 2014 at 00:04

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

27 min

58K

Programming*C++*C*

Tutorial

+59

Comments 15

HgeN Jan 31 2014 at 03:18

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

Andrey2008 Jan 31 2014 at 11:51

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

ploop Jan 31 2014 at 09:33

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

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

RPG Jan 31 2014 at 11:04

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

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

ploop Jan 31 2014 at 11:07

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

RPG Jan 31 2014 at 11:22

Если уж 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 Jan 31 2014 at 11:46

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

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

RPG Jan 31 2014 at 11:54

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

RPG Jan 31 2014 at 11:47

Ваш комментарий натолкнул действительно на интересную проблему. Я сейчас отключил в исходниках тот блок анализатора, который отвечал за блокировку классов, и повторил анализ недавнего 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 Jan 31 2014 at 12:28

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

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

Andrey2008 Jan 31 2014 at 11:56

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

+12

Next_Alex Feb 2 2014 at 13:17

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

-1

Biga Jan 31 2014 at 12:21

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

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

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

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

UFO just landed and posted this here

Biga Feb 2 2014 at 23:56

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

Show the best of all time