Andrey2008
+4
Непременно. Рад, что Вы готовы провести такое сравнение. Желаю удачи.
Andrey2008
+1
Интересно. Попробуйте.
Andrey2008
0
Примечание. Я постоянно сталкиваюсь с желанием программистов заявить, что это возможно не баг, а фича :). Пример с reddit. Мне это непонятно, зачем пытаться оправдать явно плохой, опасный и ошибочный код? В чем профит? :)

Теперь про разные моменты.

1) sockaddr_
Не важно, появится там конструктор или нет. Код неправильный. Нельзя создавать объект одного размера, а уничтожать как объект другого размера. Да везёт, что пока всё это работает и я не могу продемонстрировать обратное (быть может кто-то поможет). Сбой может произойти по разным причинам. Например, менеджер памяти реализован так, что хранит информацию об объектах разного размера в разных таблицах и использовать разные пулы памяти. И тогда, он может не найти запись об выделенной памяти в соответствующей таблице.
Или менеджер памяти особо-секьюрный и обнуляет освобождаемую память. А тут ему подсовывают объект не того размера.
Так что анализатор ведёт себя правильно и ничего в нём исправлять не надо. Надо исправлять код программы.
Вы приводите пример и говорите об наследовании с виртуальными деструкторами. Это совсем другая ситуация и в подобном случае естественно анализатор промолчит. Я ведь специально отметил в статье, что эти 3 класса никак не связаны между собой.

2) M_PI
Согласен, местами его нет. Но раз в других местах используется M_PI, то не вижу смысла городить велосипед. Первый попавшийся M_PI в C-файле (проект org.tizen.myplace-1.0.1, файл myplace-suggestedview.c):
static inline double __rad_2_deg(double radians)
{
	return radians * (180.0 / M_PI);
}


3) argv2[i] = NULL;
Это не тот argv, который приходит в main. Это нечто самобытное:
              ....
	argc = malloc(sizeof(int));
	argv = malloc(sizeof(gchar *) *max_argc);
	argv2 = malloc(sizeof(gchar *) *max_argc);

	if (!argc || !argv || !argv2)
		goto ERROR;

	memset(argv, 0, sizeof(gchar *) *max_argc);
	memset(argv2, 0, sizeof(gchar *) *max_argc);
              ....


4) Non-void function should return a value
Я неприятно удивлю, но компиляторы до сих пор проглатывают такой код. Примеры.

Andrey2008
+1
Я использовал метод выборки «пальцем в небо». Очень хороший, честный способ для решаемой задачи.

В статье перечислены проекты, которые были взяты
alsa-lib-1.0.28, aspell-0.60.6.1, augeas-1.3.0, bind-9.11.0, efl-1.16.0, enlightenment-0.20.0, ise-engine-anthy-1.0.9, bluetooth-frwk-0.2.157, capi-appfw-application-0.5.5, capi-base-utils-3.0.0, capi-content-media-content-0.3.10, capi-maps-service-0.6.12, capi-media-audio-io-0.3.70, capi-media-codec-0.5.3, capi-media-image-util-0.1.15, capi-media-player-0.3.58, capi-media-screen-mirroring-0.1.78, capi-media-streamrecorder-0.0.10, capi-media-vision-0.3.24, capi-network-bluetooth-0.3.4, capi-network-http-0.0.23, cynara-0.14.10, e-mod-tizen-devicemgr-0.1.69, ise-engine-default-1.0.7, ise-engine-sunpinyin-1.0.10, ise-engine-tables-1.0.10, isf-3.0.186, org.tizen.app-selector-0.1.61, org.tizen.apps-0.3.1, org.tizen.bluetooth-0.1.2, org.tizen.browser-3.2.0, org.tizen.browser-profile_common-1.6.4, org.tizen.classic-watch-0.0.1, org.tizen.d2d-conv-setting-profile_mobile-1.0, org.tizen.d2d-conv-setting-profile_wearable-1.0, org.tizen.download-manager-0.3.21, org.tizen.download-manager-0.3.22, org.tizen.dpm-toolkit-0.1, org.tizen.elm-demo-tizen-common-0.1, org.tizen.indicator-0.2.53, org.tizen.inputdelegator-0.1.170518, org.tizen.menu-screen-1.2.5, org.tizen.myplace-1.0.1, org.tizen.privacy-setting-profile_mobile-1.0.0, org.tizen.privacy-setting-profile_wearable-1.0.0, org.tizen.quickpanel-0.8.0, org.tizen.screen-reader-0.0.8, org.tizen.service-plugin-sample-0.1.6, org.tizen.setting-1.0.1, org.tizen.settings-0.2, org.tizen.settings-adid-0.0.1, org.tizen.telephony-syspopup-0.1.6, org.tizen.voice-control-panel-0.1.1, org.tizen.voice-setting-0.0.1, org.tizen.volume-0.1.149, org.tizen.w-home-0.1.0, org.tizen.w-wifi-1.0.229, org.tizen.watch-setting-0.0.1, security-manager-1.2.17.


Вряд ли мне «повезло» взять столько проектов, относящихся к одной команде. Почти наверняка, эти проекты создаются как минимум несколькими командами.
Andrey2008
0
Да. Как раз недавно писал рассуждения на эту тему: "Философия статического анализатора PVS-Studio".
Andrey2008
+3
Написание подобных статей, пожалуй, основной способ продвижения анализатора PVS-Studio. Люди читают, пробуют на своих проектах, покупают.
По поводу Хабра. Этот канал привёл к нам некоторое количество клиентов.
По поводу Qt не помню. Кажется, поблагодарили и поправили то, что мы нашли.
Andrey2008
0
Да, какая-то глупость написана в статье. Видимо, выписал какой-то не тот фрагмента кода. Разбираться в причинах уже сил нет, поэтому просто удалил этот фрагмент из статьи и изменил, что находим не 914, а 913 ошибок :).

P.S. Возможно и ещё что-то окажется не ошибкой при тщательном изучении. Но с другой стороны, при тщательном анализе и наоборот выяснится, что я пропускал некоторые ошибки. Например, я поленился изучать V730 (очень трудоёмко). А там наверняка несколько ошибок скрывается.
Andrey2008
+7
Конечно непостоянная. Но переживать об том есть смысл, если мы проверили 1000, 3000 или 10000 строк кода. Или стоит переживать, если проверялся только один проект написанный одной командой. Когда проверено 2400000 строк кода из множества разных проектов, вполне смело можно считать, что полученное значение плотности является средним и для оставшейся части проекта.
Andrey2008
+4
Данная картинка здесь совершенно неуместна. Прочитайте статью (хотя-бы по диагонали :-).
Andrey2008
+18
Прошу прочитать статью и тогда станет понятно, что этот подход достоверен. В данном случае 3.3% кода это 2 400 000 строк кода (без учёта комментариев). Это много, это размер некоторых проектов. Проверив такой размер кода вполне модно проводить расчеты и получить результат близкий к реальности.
Andrey2008
0
Или PVS-Studio пока ещё не умеет data flow analysis?


Умеет. Ограничено. Впрочем, любой статический анализатор в той или иной степени умеет именно ограниченно.
Andrey2008
+2
Дело в том, что существовала (к сожалению) распространённая практика хранить указатели в int. Поэтому искать такое в старых С-программах дело неблагодарное, а в C++ это уже не скомпилируется. Впрочем, можно подумать, как сделать эту диагностику с приемлемым количеством ложных срабатываний.

Сейчас PVS-Studio ругается только 64-битной диагностикой, так как нехорошо запихивать указатель в int, обрезая старшие биты: V103: Implicit type conversion from memsize to 32-bit type.
Andrey2008
0
Примеры уязвимостей, которые можно было бы выявить и предотвратить, используя PVS-Studio.
Andrey2008
+10
А вот и долгожданная большая MVP статья. Спасибо! Интересный, хороший материал. Надеюсь, это привлечёт новых энтузиастов, которые захотят попробовать получить статус MVP. От себя: рекомендую.

P.S. В статье приводится моя цитата, где ссылки никак не выделены, что может сбивать читателя с толку (по крайней мере, мои браузеры ссылку не показывают). Поэтому я решил выделить их здесь:... Я вернулся с DevCon 2012 расстроенным, что нигде нет C++ и написал вот такую заметку. Потом была пауза, но в 2013 году Сергей Платонов пишет заметку, что хочет создать C++ User Group в России....
Andrey2008
+9
NaN всегда неравен NaN.
Andrey2008
+1
Моё новое интересное исследование: Зло живёт в функциях сравнения.
Andrey2008
0
А какая нам разница, как с Tizen в России? Главное, что в целом сейчас эта ОС активно развивается и продвигается.

P.S. Команда PVS-Studio готова поработать над проектом Tizen (открытое письмо)
Andrey2008
–1
Думаю, никакой проблемы нет. Точечные предупреждения размечаются как //-V501 и их легко найти. Макросы да, размечаются так //-V:qqq:501, но так ли много будет таких случаев? Тем более что такой комментарий логично написать рядом с макросом и соответственно его можно будет легко найти, когда захочется продемонстрировать кому-то подавление предупреждение в этом самом макросе.

Если вдруг надо подавлять много предупреждений в разных макросах или нельзя менять заголовочные файлы, то можно собрать всё это в pvsconfig файлы. См. в документации о подавлении ложных срабатываний раздел «Массовое подавление ложных предупреждений с помощью файлов конфигурации диагностик pvsconfig». Соответственно, раз всё собрано в одном месте, опять-таки будет легко найти всё что, нужно.
Andrey2008
0
Пока не поддерживается, но в todo записано. Про собственные форматы символов анализатор ничего не знает. Если пометить, что это аналог printf, то анализатор будет ругаться на нестандартные управляющие символы.
Andrey2008
0
И что-бы вообще отключать диагностику: //-V::501
Andrey2008
0
Что-бы можно было писать: -V:Q_ASSERT:501,502,555
Andrey2008
0
Уже отвтили, но на всякий случай ссылка: Подавление ложных предупреждений (см. Подавление ложных предупреждений в С/С++ макросах (#define) и для других фрагментов кода).
Andrey2008
+1
Да, такоей механизм уже есть. См. описание диагностики V576 (раздел «Дополнительные возможности»).
Andrey2008
+2
Да, но без потери производительности. В любой момент можно использовтаь те технологии, чтобы получить эффективность Си.
Andrey2008
0
А вот я добрался и до Tizen. Путь будет длинным, но интересным. Ведь как гласит реклама:
Тайзен — единственная сертифицированная в России операционная система для построения эффективной платформы мобильных решений для государственных и корпоративных предприятий.
А что внутри? Видимо всё как обычно:

full_path = (char *)alloca(PATH_MAX);
....
free(full_path);


Будет статья от команды PVS-Studio, будет! :)
Andrey2008
+2
Эх, если бы это действительно было так и мы были всем известны… :(

Вы преувеличиваете. Просто так совпало, что Вы присутствуете на тех же площадках, что и мы. Вот и создаётся впечатление, что мы везде. У нас на эту тему даже заметка есть: "Ох, опять они со своим PVS-Studio. Везде они...".

В реальности же, мы никому не знакомы, даже в России. Например, приезжаешь на семинар в МЦСТ. Собралось около 25 программистов. Из них про PVS-Studio слышали около двух человек. Вот такие суровые реалии…
Andrey2008
0
И здесь молчит. Хочу сказать, что мне не нравится подобные рассуждения и эксперименты на основе подобных тестов. Прошу почитать: Почему я не люблю синтетические тесты.
Andrey2008
+1
Анализтор промолчал в обоих случаях. Во втором случае стоит что-то сказать, взял на карандашь. Спасибо.
Andrey2008
0
На это автор кода может возразить

Может. Это его право. Задача статического анализтора указать на подозрительный код. Задача программиста оценить это сообщение и предпринять меры, если они нужны или подавить предупреждение.
Andrey2008
+3
Освобождение памяти отсутствует сознательно. Удаление сотен тысяч отдельных объектов это медленно. Впрочем, их можно почистить быстрее, так как для их выделения используется свой собственный менеджер памяти. Но даже он отключен, так как всё равно это пустая потеря времени.

Механизм освобождения в менеджере памяти используется только при прогоне юнит-тестов, чтобы не сжирать слишком много памяти при проверке различных тестовых *.i файлов. В случае же работы в пользовательском режиме память освобождает операционная система, завершая процесс. Такой подход экономит порядка 0.1 секунду (значение приблизительное, давно не замерял время) на запуск. Проверили 1000 файлов и вот уже экономия в 100 секунд: приятно.
Andrey2008
0
Пока не пробовали. Там ожидаемо будет 100500 утечек памяти, так как узлы дерева не удаляется в процессе работы, так как построенное дерево используется до конца работы программы. А в конце просто завершить программу, без предварительного удаления дерева. Этакая оптимизация скорости работы.