Comments 12
Стандартное нытьё про проверку freeswitch ;)
В статье описаны по большому счету маленькие, нефатальные ошибки, поэтому с The Powder Toy не все так уж и плохо.
А вот мне интересно рекурсивное поведение — проверить запущенный инстанс самого себя.
Такое делалось?
Такое делалось?
В смысле проверить исходные коды PVS-Studio с помощью PVS-Studio? Или что Вы имели в виду?
Вы прочитали то, что написано под «Прочитали статью и есть вопрос?»? :-)
Вот мне интересны такие вещи. Проект относительно небольшой, всего 2.1Мб кода (*.c, *.h, *.cpp). Сколько всего сообщений выдало PVS-Studio на этом проекте? В статье упомянуто около двух десятков. Какая это доля от всех сообщений? Остальные слишком скучны для статьи или это ложные сработки? Можете ли вы оценить долю ложных сработок? Понятно, что не всегда возможно сказать наверняка, ложная она или нет, но приблизительно же можно посчитать? Для простоты можно считать, что 64битные сообщения (V101-V303) нас пока не интересуют. Приведите примеры характерных ложных сработок.
Мы сознательно не приводим информацию о ложных срабатываниях, чтобы почём зря не создать негативное впечатление. Часто анализатор выдаёт много ложных срабатываний, многие, которые можно легко и быстро изничтожить. Занимаясь проверкой сторонних проектов, мы этого не делаем. Наша цель написать статью, поэтому можно и потерпеть мусор среди сообщений. Но человек, работая со своим проектом, думаю может весьма хорошо настроить анализатор и ложных срабатываний будет не так уж и много.
Что-бы пояснить данный момент на практике, приведу фрагмент из статьи "Третья проверка кода проекта Chromium с помощью анализатора PVS-Studio".
Мне часто задают вопрос:
В статьях вы очень ловко приводите примеры найденных ошибок. Но вы не говорите, каково общее количество выдаваемых сообщений. Часто статические анализаторы выдают очень много ложных срабатываний и среди них практически невозможно отыскать настоящие ошибки. Как дело обстоит с анализатором PVS-Studio?
И я всегда не знаю, что сходу ответить на этот вопрос. У меня есть два противоположных ответа: первый — много, второй — мало. Все зависит, как подойти к рассмотрению выданного списка сообщения. Сейчас на примере Chromium я попробую объяснить суть такой двойственности.
Анализатор PVS-Studio выдал 3582 предупреждений первого уровня (набор правил общего назначения GA). Это очень много. И в большинстве этих сообщений являются ложными. Если подойти «в лоб» и начать сразу просматривать весь список, то это очень быстро надоест. И впечатление будет ужасное. Одни сплошные однотипные ложные срабатывания. Ничего интересного не попадается. Плохой инструмент.
Ошибка такого пользователя в том, что не выполнена даже минимальная настройка инструмента. Да, мы стараемся сделать инструмент PVS-Studio таким, чтобы он работал сразу после установки. Мы стараемся, чтобы ничего не надо было настраивать. Человек должен просто проверить свой проект и изучить список выданных предупреждений.
Однако так не всегда получается. Так не получилось и с Chromium. Например, огромное количество ложных сообщений возникло из-за макроса 'DVLOG'. Этот макрос что-то логирует. Он написан хитро и PVS-Studio ошибочно посчитал, что в нем может быть ошибка. Поскольку, макрос очень активно используется, ложных сообщений получилось очень много. Можно сказать, что сколько раз используется макрос DVLOG, столько ложных предупреждений попадет в отчет. А именно, о макросе было выдано около 2300 ложных сообщений «V501 There are identical sub-expressions.....».
Можно подавить эти предупреждения, вписав в заголовочный файл, рядом с объявлением макроса, вот такой вот комментарий:
//-V:DVLOG:501
Смотрите, таким простым действием мы вычтем из 3582 сообщений, 2300 ложных. Мы сразу отсеяли 65% сообщений. И теперь нам не надо их зря просматривать.
Без особых усилий можно сделать ещё несколько подобных уточнений и настроек. В результате, большинство ложных срабатываний исчезнут. В некоторых случаях после настройки следует перезапускать анализ, в некоторых нет. Подробнее всё это описывает в документации раздел "Подавление ложных предупреждений". Конкретно, в случае с ошибками в макросах, придется перезапускать анализ.
Надеюсь теперь понятно. Почему первый ответ — ложных срабатываний много. И почему второй ответ — ложных срабатываний мало. Всё зависит, готов ли человек потратить хоть немного времени на изучение продукта и способов избавить себя от лишних сообщений.
Что-бы пояснить данный момент на практике, приведу фрагмент из статьи "Третья проверка кода проекта Chromium с помощью анализатора PVS-Studio".
Мне часто задают вопрос:
В статьях вы очень ловко приводите примеры найденных ошибок. Но вы не говорите, каково общее количество выдаваемых сообщений. Часто статические анализаторы выдают очень много ложных срабатываний и среди них практически невозможно отыскать настоящие ошибки. Как дело обстоит с анализатором PVS-Studio?
И я всегда не знаю, что сходу ответить на этот вопрос. У меня есть два противоположных ответа: первый — много, второй — мало. Все зависит, как подойти к рассмотрению выданного списка сообщения. Сейчас на примере Chromium я попробую объяснить суть такой двойственности.
Анализатор PVS-Studio выдал 3582 предупреждений первого уровня (набор правил общего назначения GA). Это очень много. И в большинстве этих сообщений являются ложными. Если подойти «в лоб» и начать сразу просматривать весь список, то это очень быстро надоест. И впечатление будет ужасное. Одни сплошные однотипные ложные срабатывания. Ничего интересного не попадается. Плохой инструмент.
Ошибка такого пользователя в том, что не выполнена даже минимальная настройка инструмента. Да, мы стараемся сделать инструмент PVS-Studio таким, чтобы он работал сразу после установки. Мы стараемся, чтобы ничего не надо было настраивать. Человек должен просто проверить свой проект и изучить список выданных предупреждений.
Однако так не всегда получается. Так не получилось и с Chromium. Например, огромное количество ложных сообщений возникло из-за макроса 'DVLOG'. Этот макрос что-то логирует. Он написан хитро и PVS-Studio ошибочно посчитал, что в нем может быть ошибка. Поскольку, макрос очень активно используется, ложных сообщений получилось очень много. Можно сказать, что сколько раз используется макрос DVLOG, столько ложных предупреждений попадет в отчет. А именно, о макросе было выдано около 2300 ложных сообщений «V501 There are identical sub-expressions.....».
Можно подавить эти предупреждения, вписав в заголовочный файл, рядом с объявлением макроса, вот такой вот комментарий:
//-V:DVLOG:501
Смотрите, таким простым действием мы вычтем из 3582 сообщений, 2300 ложных. Мы сразу отсеяли 65% сообщений. И теперь нам не надо их зря просматривать.
Без особых усилий можно сделать ещё несколько подобных уточнений и настроек. В результате, большинство ложных срабатываний исчезнут. В некоторых случаях после настройки следует перезапускать анализ, в некоторых нет. Подробнее всё это описывает в документации раздел "Подавление ложных предупреждений". Конкретно, в случае с ошибками в макросах, придется перезапускать анализ.
Надеюсь теперь понятно. Почему первый ответ — ложных срабатываний много. И почему второй ответ — ложных срабатываний мало. Всё зависит, готов ли человек потратить хоть немного времени на изучение продукта и способов избавить себя от лишних сообщений.
Здравствуйте, Андрей! Спасибо за развёрнутый ответ, хотя я всё же хотел увидеть конкретные цифры. Я же не как потенциальный пользователь интересуюсь, а скорее как коллега ;-) Впрочем, раздел документации частично проясняет ситуацию. Про массовую фильтрацию, конечно, понятно. К примеру, IntelliJ IDEA скомпилирована с какой-то хитрой штуковиной вроде Lombok, которая на выходе функции, помеченной Notnull автоматом вставляет в байт-код проверку и assert, если мы пытаемся вернуть null. С точки зрения FindBugs подавляющее большинство таких проверок лишнее, в результате имеется свыше 11000 ложных сообщений Redundant nullcheck of value known to be non-null (а всего 28000 сообщений на всём проекте). Если перекомпилировать без этой штуки или отключить этот варнинг, то доля ложных сработок резко падает.
Кстати, тут не ошибка (это из вашей документации)?
Кажется, << лишнее в комментарии.
Всё же я думаю, что самое лучшее впечатление — это когда оно соответствует истине. В любой научной статье новый метод или алгоритм не только расхваливается, но и указываются пределы его применимости и возможные проблемы. Ваш продукт всё же на умных людей рассчитан. Взвешенные статьи с указаниями не только преимуществ, но и характерных недостатков (в виде пары интересных ложных срабатываний) смотрелись бы весомее. Может, конечно, я ничего не понимаю в маркетинге :-)
Кстати, тут не ошибка (это из вашей документации)?
//-V:ABC<<:501
AB C = x == x; // Есть предупреждение
AB y = ABC == ABC; // Нет предупрежденияКажется, << лишнее в комментарии.
Всё же я думаю, что самое лучшее впечатление — это когда оно соответствует истине. В любой научной статье новый метод или алгоритм не только расхваливается, но и указываются пределы его применимости и возможные проблемы. Ваш продукт всё же на умных людей рассчитан. Взвешенные статьи с указаниями не только преимуществ, но и характерных недостатков (в виде пары интересных ложных срабатываний) смотрелись бы весомее. Может, конечно, я ничего не понимаю в маркетинге :-)
Предупреждения общего назначения:
Первый уровень: 29
Второй уровень: 72
Третий уровень: 208 (по умолчанию отключены)
Что есть ложное, а что нет, сказать сложно. Например, на третьем уровне почти 100 предупреждений V688. Вроде и не ошибка, но сообщение по делу. Пример:
V688 The 'l' function argument possesses the same name as one of the class members, which can result in a confusion. luawindow.cpp 179
Плохая идея делать член класса с именем 'l' и при этом также называть аргумент функции. Легко запутаться, с каким 'l' нужно работать.
По поводу документации. Да, ошибка. Спасибо, исправим.
Первый уровень: 29
Второй уровень: 72
Третий уровень: 208 (по умолчанию отключены)
Что есть ложное, а что нет, сказать сложно. Например, на третьем уровне почти 100 предупреждений V688. Вроде и не ошибка, но сообщение по делу. Пример:
class LuaWindow
{
....
lua_State * l;
....
};
int LuaWindow::size(lua_State * l)
{
....
};
V688 The 'l' function argument possesses the same name as one of the class members, which can result in a confusion. luawindow.cpp 179
Плохая идея делать член класса с именем 'l' и при этом также называть аргумент функции. Легко запутаться, с каким 'l' нужно работать.
По поводу документации. Да, ошибка. Спасибо, исправим.
Ясно, спасибо. В целом цифры разумные. Про V688 никаких вопросов. Понятно, что есть прямо ошибки, а есть неаккуратность или плохой стиль. Если пользователю не нравится конкретная диагностика, он может её отключить. Ложными срабатываниями я считаю ситуации, когда текст сообщения об ошибке неверен, именно такой код и задумывался и исправлять нечего. Например, в случае с V688 если бы на самом деле не было члена класса с таким именем, это было бы ложное срабатывание (понятно, что конкретно эта диагностика простая и вряд ли для неё вообще возможны ложные срабатывания).
Sign up to leave a comment.
Проверка симулятора The Powder Toy