Из подвала секретной лаборатории разработчиков PVS-Studio…

Ваши подозрения немного не верны. В регулярном режиме перед каждым сабмитом запускаю target в основном makefile проекта, который, в свою очередь, вызывает cppcheck и cpplint для всех файлов.

> Этот фрагмент комментария мне не понятен. А что сейчас мешает взять и смотреть plog файл? И какое отношение к этому имеет Clang?

Вопрос не о смотреть, вопрос о создании лога. См. верхний комментарий ветки. Clang построен таким образом, что его можно внедрить, например, в CI-систему. A куда можно внедрить плагин студии кроме студии? Кстати, о внедрении clang вы точно знаете, т. к. сами его используете.

Это вы разработчикам из гугла предлагаете добавлять комментарии вида "//-V:DVLOG:501" к макросам с тысячами использований? У Chromium один из самых здравых подходов к использованию возможностей C++. Если бы они на каждый баг вашего анализатора (это не «Он написан хитро», это именно неинтеллектуальность анализатора) приписывали абсолютно нечитаемые комменты (как иначе понимать 501?), а затем ещё и дефайны предупреждений для VC++, ICC, а затем ещё и всякие "#pragma GCC diagnostic ignored "-Wformat"", то код просто бы превратился в помойку, и лишь анализатор был бы доволен таким кодом.

Следующее действие — отключение проверок на уровне анализатора. Но что отключать, когда бажит почти каждая проверка? Вот вы говорите, что анализатор хорошо находит опечатки. Для стороннего человека может показаться, что вот эта находка действительно интересна. И лишь разработчик знает, что этот участок кода отвечает за иконки, а иконки в Blender всегда квадратные (и это заложено очень глубоко в коде).

Проверки на опечатки в мат-софте хочется отключить первым делом: ругается на любую последовательность f(x1, y2); f(x1, y1); f(x2, y1); при более-менее нетривиальной перестановке x1/x2/y1/y2. Сколько сотен нужно просмотреть ложных срабатываний, чтобы потом найти опечатку, которая не влияет на результат?

Кстати, на этой же странице вы пишете про SAFE_RELEASE, но тут же приводите пример обычного мёртвого кода for (; surface; surface=surface->next) { PaintSurfaceData *sData = surface->data; if (surface &&. Интеллектуальный анализатор (clang) видит, что проверка surface уже произведена в условии цикла, а значит нулевой указатель никогда не будет разыменован. Т. е. в clang уже есть аналогичная проверка, но без очевидных ложных срабатываний.

В разделе «Misprint in code clearing an array» вы пишете о двойном clean и советуете поменять averts на anorms, но при этом вы даже не задумались о том, почему этот код ещё не исправили. А не исправили потому, что он мёртвый: он очищает уже чистые массивы. И эта проверка в принципе бажная, потому что вы проверяете код после препроцессора, и он считает, что int f(){return LEFT_TOP;} и int f(){return ANIM_SYSTEM;} одинаковы, если LEFT_TOP и ANIM_SYSTEM определены через #define с одним числом.

Раздел «Double check» — ни одной ошибки, обычные излишне-скурпулёзные проверки.

Раздел «Odd comparisons» — это вам они кажутся странными, на самом деле такой API у обёртки питона. И снова сотни ложных срабатываний.

Как вы поняли, 71113 выхлопов в проекте Blender на полной сборке. Да, это м-м-м-максимум диагностик со всех уровней, что в принципе глупо, с этим я не спорю. Но даже убрать всё, кроме первого уровня (а многие проверки из статьи на втором и даже на третьем уровнях), то что после этого дополнительно отключать? Проверки на неправильные unsigned-сравнения? Проверки на разыменование перед проверкой на нуль? Проверки на повторный код? И что останется после отключения всех бажных проверок?

Благодарю за разъяснения.

ну если есть основные, тогда не вижу проблем с вариантом 1. Вместо написания плагинов, можно оформить это в виде standalone а данные из проектных файлов брать при натравливании тулзы на папку с проектом.

Мы ж не используем вижуал студио, у нас практически все проекты — ембеддед. И когда я игрался с эвалюэйшн, вы же мне и ответили, что для проекта не в студии работать не будет, а если и будет, то неэффективно. А эта статья как раз и обещает, что можно будет работать и не в студии тоже.

You can't be too safe!