Так оно и есть. К сожалению, для индустрии, многие никак не могут осознать, что вывод анализатора нужно держать чистым. А ведь это уже давно описано, разобрано и обсуждено для предупреждений компилятора. Когда накапливаются предупреждения компилятора, люди перестают их читать, они перестают помогать, а только мешают. Именно отсюда растут ноги у ключей компилятора, заставляющих интерпретировать предупреждения как ошибки.
Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.
Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию. Используя административные рычаги, он может заставить не оставлять варнинги и внедрять анализаторы. Вот так и живём.
Это называется гипербола (стилистическая фигура явного и намеренного преувеличения, с целью усиления выразительности и подчёркивания сказанной мысли). Конечно не всем, но мы видим что это действительно есть, и даже в обсуждении этой статьи. Поэтому и захотелось обратить внимание на этой читателей. И мне кажется, это удалось и завязывается интересная дискуссия.
Эх, вот бы кто-то по отчёту прошёлся, касающегося недавней проверки FreeBSD и смог бы использовать как-то баг, превратив его в уязвимость. Нам бы для рекламных целей было полезно. :) Я даже наградить такого человека готов. Самим у нас не хватает сил и времени.
Мы перепроверили с помощью PVS-Studio свежую версию исходных кодов проекта FreeBSD. Git revision: 59fe28863e6a0903b50b37c616f21a2a865bbbf2
Мы немного поработали с отчетов, отфильтровав явно лишние на наш взгляд сообщения. В списке конечно всё равно осталось много ложных срабатываний, но дальше уже нет возможности убирать лишние предупреждения крупными группами. Оставшиеся предупреждения следует смотреть по отдельности.
Отчет выкладываем в двух форматах (tasks и csv). Тому, кто будет работать с отчетом в начале следует произвести автоматическую замену SOURCE_ROOT на нужный путь, чтобы правильно заработала навигация.
Трудно. Мы используем внешний препроцессор и не контролируем процесс раскрытия. Но даже если бы контролировали, это не сильно что-то даст. Допустим мы видим где и как раскрывается макрос. Что дальше? Один раз макрос раскрылся в одном файле. Один раз в другом и так далее. Нужно ещё как-то понять взаимосвязь. Да и вообще, а кто сказал, что в макросе не может быть ошибки, которая к ужасу ещё и размножена?
Кстати, чтобы найти ошибку в первом фрагменте кода, вовсе не обязательно запускать программу под присмотром valgrind. Подобные простые случаи сходу выявляет и статический анализатор кода. Например, PVS-Studio выдаёт 2 предупреждения:
V512: A call of the 'strcpy' function will lead to overflow of the buffer 'str'.
V575: The potential null pointer is passed into 'strcpy' function. Inspect the first argument.
Первое по делу. Второе про то, что указатель, выделенный через malloc() хорошо-бы проверить перед использованием.
Если честно, я не уловил суть. Как по мне, в независимо от того, насколько хорошо мы можем анализировать макросы, одинаково сложно понять, надо ругаться на 1.3 == 2, или нет. Поэтому прошу сформулировать поподробнее.
Кстати, мы никогда не утверждали, что пишем идеальный код и у нас есть смелость сказать про это. Думаю, в этом есть польза. Польза конечно не том, что код не идеален, а в том, что признаем это. Благодаря этому у нас нет гордыни и мы спокойно используем различные методики для повышения качества и надежности кода (разные виды тестов, проверяем себя с помощью PVS-Studio, Clang и т.п.). Мы просто столько везде слышим пафосного, что вот мы то о-го-го и таких-то ошибок не совершаем. Вот только откуда же тогда вот эти 10893 ошибки… Никак инопланетяне по ночам в код их подмешивают. Впрочем, ничего нового, все мы считаем себя чуть лучше, чем есть средний программист.
Ругаться на неименованные константы нельзя, кроме особых случаев. Вернее, ругаться можно на все константы, но как только в анализаторе появятся такие предупреждения, он превратится в тыкву.
Предположу, что слишком много шума (ложных срабатываний) у компиляторов, вот и не пользуются. Это когда рассматриваешь отдельные случаи, то все кажется просто и даже в выводе компилятора можно найти нужное. Но на практике всё это теряется в шуме бессмысленных предупреждений. Мы же очень много работаем не только над поиском многих паттернов ошибок, но и ещё очень много работаем над исключениями. Чтобы шума было меньше. Это ОЧЕНЬ важно.
Но воз и ныне там. Мы проверяем много проектов и видим, что при компиляции многие проекты страдают «недержанием предупреждений». При компиляции выводятся сотни warnings.
Собственно, та же самая картина и с анализаторами кода. И, опять-таки к сожалению, часто только менеджер может изменить ситуацию. Используя административные рычаги, он может заставить не оставлять варнинги и внедрять анализаторы. Вот так и живём.
См. комментарии ниже. :)
Мы перепроверили с помощью PVS-Studio свежую версию исходных кодов проекта FreeBSD. Git revision: 59fe28863e6a0903b50b37c616f21a2a865bbbf2
Мы немного поработали с отчетов, отфильтровав явно лишние на наш взгляд сообщения. В списке конечно всё равно осталось много ложных срабатываний, но дальше уже нет возможности убирать лишние предупреждения крупными группами. Оставшиеся предупреждения следует смотреть по отдельности.
Отчет выкладываем в двух форматах (tasks и csv). Тому, кто будет работать с отчетом в начале следует произвести автоматическую замену SOURCE_ROOT на нужный путь, чтобы правильно заработала навигация.
Tasks: http://cppfiles.com/freebsd.plog.tasks
Csv: http://cppfiles.com/freebsd.plog.csv
Первое по делу. Второе про то, что указатель, выделенный через malloc() хорошо-бы проверить перед использованием.