Про статический анализ С++

не то что бы я занимался.
даже не то что бы мне давали пощупать.
но у меня сложилось впечетление, что gcc со всеми максимальными ворнингами дает результаты, сравнимые со всеми системами статического анализа.
ну и так же ложно срабатывает, да. примерно в тех же местах.

Есть такое мнение про системы статического анализа (да и вообще про все отладочно-дебажные тулзы, про тот же valgrind) - их нужно использовать более-менее регулярно, на всём процессе разработки.
Всякие очепятки, которые пропустил компилятор и которые приводят к фактическим ошибкам, рано или поздно повылазят, их разработчик самостоятельно пофиксит, без статических чекеров, просидев часик-другой в отладчике.
В результате такая ситуация и возникает - на практически готовый продукт натравливают всякий lint, он показывает ересь, бред и ложные срабатывания, потому, что разраб уже всё пофиксил.

> Но в реальной жизни бывает два вида layout - и это явно прописано в вызывающем коде. Т.е. у машинки достаточно данных, чтобы сообразить, что это не 'High impact', а просто неаккуратненько.

Э, нет, батенька, не согласен я с вами тут.
Это сегодня явно прописано строго два варианта вызова и никаких больше. А завтра в проект придёт новый чувак, которому поставят задачу сделать третий лейяут и он имеет полное право не знать о таком неявном свойстве кода, посему будет честное обращение к неинициализированной памяти.
Это очень правильный ворнинг, имхо. Это не "неаккуратненько", это мина на будущее расширение.
Я бы переписал тот код как свитч с throw exception по дефолту.

> С этим я не хочу спорить - формально машинка права, а по факту в этих unsigned short живут размеры картинки и до 32767 они в ближайшие годы не дорастут.

))) "640кб хватит всем!", "до 2000-го года ещё много лет, успеем поправить!" :)
Ну, т.е. понятно, что машина-то всех тонкостей domain specific не знает, посему имхо тоже вполне правильно ругается.

> В частности, любимый коффиновский метод проверки диапазона значений 0..N одним действием машинка просто не чует:

А чо-как ругается? Вполне нормальный метод, имхо...

По вопросу: я специально не использую, но обычно ставлю студию на наивыший уровень ворнингов и если что возникает - стараюсь или переправлять, или если однозначно в данном случае не нужно - подавлять. Несколько раз меня эти варнинги ОЧЕНЬ спасали от тяжелого и трудноуловимого дебуга, поэтому просто принял для себя решение по возможности сразу писать правильно и таки прислушиваться в варнингам. Хотя специально отдельными тулзами обычно не пользуюсь. Согласен с тем, что в идеале это надо делать системным образом, но по моему опыту даже вот такое эпизодическое следование мне лично здорово помогало.

Мы используем, тот же Coverity. False positive'ов много, и вычищать было мучительно, но по ощущениям - польза от этого действия есть. Глупости всякие успешно отлавливает, вроде вот таких - http://trac.nginx.org/nginx/changeset/4937/nginx.

для С++ с его указателями гораздо полезнее valgrind, который может проверять очень многие вещи.
в целом, я скорее за статические анализаторы, ибо они дисциплинируют. ложные срабатывания можно отметить (а можно немного переписать код), но даже если 1 из 10 срабатываний не ложное, это хороший результат.
главное же средство борьбы с багами было и есть: простой и понятный код, покрытие тестами, грамотный логгинг, специальный дебаг режим с пред и постусловиями.

Про Clang тут уже говорили, а про cppcheck вроде бы нет. Хорошая оупен-сорсная утилита для статического анализа.

Прочитал заметку о проверке маленького проекта LibRaw с помощью Coverity SCAN. Из статьи следует, что ничего интересного не нашлось. Решил попробовать, сможет ли найти что-то анализатор PVS-Studio.

Читать далее: http://habrahabr.ru/company/pvs-studio/blog/211727/