Информация

Дата основания
2008
Местоположение
Россия
Сайт
www.viva64.com
Численность
31–50 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 65
А почему для Cppсheck включены только errors и warnings? Если уж считать результативность анализа в найденных штуках, было бы честно сделать --enable=all, а неинтересные сообщения отсеивать через --suppress.

Он, кстати, будет работать значительно медленнее, если в проекте много вложенных веток препроцессора. Они обычно плодятся как раз в процессе отладки, а в более-менее финальной версии режутся. Поэтому если проверять чужие проекты — да, будет быстро. Если свои в самом разгаре рабочего процесса — быстро не получится. Можно, конечно, поотсекать отладочные ветки через -U, но это надо постоянно перенастраивать анализатор под проект. Да и не факт, что отладочные ветки не нуждаются в анализе.
А почему для Cppсheck включены только errors и warnings?

Потому, что тогда нужно включать на максимум PVS-Studio и Visual Studio. И тогда 170 человеко-часов, потраченные на исследование, превратятся в 600. При этом, включение малоприоритетных диагностик не сможет изменить картину, ибо это рекомендации, а не серьезные ляпы. Если хотите, можете заняться :). Мы все будем признательны.

Fair enough. Действительно, разгребать всякие inconclusive, performance и portability может быть весьма непросто. Но как раз самые серьезные ляпы там и находятся. Например, у меня недавно было inconclusive срабатывание такого типа:

memset(ctx, 0, sizeof(ctx));

(warning, inconclusive) Size of pointer 'ctx' used instead of size of its data.


Это действительно ляп, ляп неприятный и плоходиагностируемый.

Или, например:

if(time_cicl<0) time_cicl+=86400;

(style) The unsigned variable 'time_cicl' will never be negative


Очевидная ошибка программиста.

Или так:
if((bResultRead[0].bPortValue1[28]&2)!=1)

(style) The expression '(X & 0x2) != 0x1' is always true


Очень много действительно важного идет как style. Практически все логические ошибки, дубли веток, мертвый код и так далее. Но да, вычленять это все среди рекомендаций непросто.
Какой н*** это style… Ошибки вида memset(ctx, 0, sizeof(ctx)); это самые настоящие ошибки. Тьма их.

if(time_cicl<0) — и это не style, а ошибки. Тьма их.

Если анализатор, не может выдать приемлемое количество опасных сообщения, а пихает всё в style, это плохой анализатор. Мы вот можем отбросить много безопасных случаев, когда unsigned < 0 это нормально. Была проделана большая работа. Имеем право требовать и от других.

А то так вообще можно «идеальный» анализатор написать. Ругаться на каждую строчку: «Использовать Си++ это плохой стиль. Проверьте эту строку коду». Profit.
Честь и хвала вашей категоризации. Но требовать того же от других людей вы не в праве, они у вас в долг ничего не брали. Ровно как и ваши пользователи.
А мы обсуждаем методику исследования, или хорошесть Cppcheckа?
> много безопасных случаев, когда unsigned < 0 это нормально

Почему unsigned < 0 вообще может быть нормально?
Безопасно — очевидно. А нормально?
Действительно любопытно, опыта в C++ не очень много.
Например, это могут быть хитрые, но безобидные макросы.
Не совсем понял, как у вас вышло за 5 минут проверить source-sdk. Я взял все скопом с официального репозитория, запустил cppcheck на четырех ядрах i3-2330M — и он молотил код примерно 20 часов.

Получилось так:
2 — (error) Analysis failed
2 — (error) Internal error
2 — (error) Invalid number of character * when these macros are defined
2 — (error) Mismatching allocation and deallocation
2 — (error) Uninitialized variable
2 — (error) printf format string has * parameters but only * are given
2 — (portability) Extra qualification '*' unnecessary and considered an error by many compilers.
2 — (performance) Possible inefficient checking for '*' emptiness.
2 — (style) Found duplicate if expressions.
2 — (style) Variable '*' is allocated memory that is never used
2 — (warning) '*' should check for assignment to self
2 — (warning) Suspicious pointer subtraction
2 — (warning) memset() called to fill * bytes of '*'
4 — (style) Clarify calculation precedence for * and?
4 — (style) Checking if unsigned variable '*' is positive is always true.
4 — (style) Unused private function '*'
4 — (style) Variable '*' is not assigned a value
4 — (warning) Using char type as array index
6 — (error) Array '*' index * out of bounds
6 — (error) Memory leak
6 — (performance) Prefer prefix +±- operators for non-primitive types.
6 — (style) The struct '*' does not have a constructor.
6 — (warning) Redundant assignment of "*" to itself
8 — (error) Resource leak
8 — (style) Unused variable
10 — (warning) A boolean comparison with the string literal "*" is always true.
10 — (error) Null pointer dereference
12 — (style) Checking if unsigned variable '*' is less than zero.
24 — (style) struct or union member '*' is never used
32 — (style) Same expression on both sides of '*'.
38 — (error) Possible null pointer dereference
38 — (style) Consecutive return, break, continue, goto or throw statements are unnecessary
76 — (style) Statements following return, break, continue, goto or throw will never be executed
158 — (warning) scanf without field width limits can crash with huge input data
182 — (warning) Redundant code
256 — (style) Variable '*' is assigned a value that is never used
334 — (style) The scope of the variable '*' can be reduced
348 — (style) The class '*' does not have a constructor.
1438 — (information) Interrupted checking because of too many #ifdef configurations.
1728 — (style) C-style pointer casting
4720 — (warning) Member variable '*' is not initialized in the constructor.

Total: 9496


Ну в общем да, собственно ошибок немного. Очень много всего зато считается как style. Например, мертвый код после брейка, одинаковые выражения в сравнении и мои любимые проверки беззнаковых типов на отрицательность. Я согласен, что такая категоризация говорит не в пользу анализатора, но это все-таки не 27 срабатываний, заявленных в исследовании.

Видимо, Вы включили режим проверки всех возможных сочетаний условной компиляции. В таком режиме анализатор работает на порядок дольше. Об это свидетельствует «1438 — (information) Interrupted checking because of too many #ifdef configurations». Да, он может найти немного больше ошибок. Но сильно на результат это не влияет. Зато крайне усложняет (замедляет) процесс сравнения. Да и опять-таки нас будут критиковать, если мы напишем, что Cppcheck работает часы, а PVS-Studio минуты.

К сожалению, люди решили, что мы приукрасили результаты. А мы только не приукрасили, мы наоборот постарались исключить некоторые моменты, которые покажут ещё большее лидерство PVS-Studio и CppCat. Что было бы, если мы написали про 20 часов?

По поводу 27 срабатываний, которые мы отметили. Как говорилось в статье (которую к сожалению, мало кто читал из отминусовавших нас :), мы выписывали не количество срабатываний, а количество ошибок (или очень похожих на них фрагментов кода). Да, мы смотрели предупреждения. Это трудоемко и занимает много времени. Но мы сделали это. Какие именно предупреждения на наш взгляд опасны, были перечислены в SCA_Comparison.xlsx. Подробности, как мы отбирали предупреждения, опять таки приведены в пояснительной статье.
Да нет, я проверял только стандартные 12 веток по умолчанию. А Interupted checking как раз говорит о том, что --force я не трогал.

Я проводил сравнение анализаторов для своего работодателя около года назад. Тогда как раз и пришел к выводу, что Cppcheck работает долго и большая часть настоящих предупреждений относится к стилю. Почему и высказал замечание по поводу ваших результатов первым же комментарием. Я, кстати, нисколько не имел в виду какое-либо «украшательство» результатов, лишь то, что с набором проверок по умолчанию Cppcheck действительно малополезен.
Согласен, сравнение настроек по умолчанию — это не очень интересно. Интереснее везде включить полный отчет, и сравнить как число реальных ошибок, так и ложных срабатываний.
Сравните. Гы-гы. Как закончите, напишите здесь статью (лет через пять :-).
Я понимаю, что это очень непросто, и понимаю, почему сделано так, как сделано. Но от обвинений в предвзятости сравнения, особенно при таких результатах, вам отбиваться придется. :)
Не вижу ничего предвзятого в использовании рекомендуемого режима работы инструментов. Как раз наоборот, выкрутив все ручки «на полную» можно получить вообще неадекватные результаты, которые также будут критиковать.
Почему нет про ложные срабатывания, рассказано в расширенной статье.
Мы на эту задачу потратили 170 часов. Сколько секунд Вы потратили на свой комментарий? :-)
А это не важно. Критикуется суть методологии постановки эксперимента: если она неверна, то обвинять в потраченных впустую можно только свою глупость.

А суть критики в чем: есть большие сомнения, что в указанных продуктах выставлены не репрезентативные опции. Я, к примеру, использую максимальный уровень для cppcheck и есть сомнения, что пользователи ваших продуктов в массе своей используют теже опции, что и вы в своем тестировании.

Также не приведена кросс-корреляция выдаваемых предупреждений в продуктах: очень важно знать какие ошибки нашли все продукты, а какие только PVS -студия.

Хотя честь вам и хвала, что выложили весь список обнаруженных ошибок. Проделана большая работа, но не обессудьте, в ней есть изъяны.

Также не приведена кросс-корреляция выдаваемых предупреждений в продуктах: очень важно знать какие ошибки нашли все продукты, а какие только PVS -студия.

Можно легко получить такие сведения, обработав таблицы. Для этого всё и сделано в Excel, чтобы легко людям можно было сделать интересующую их выборку.
А у вас задача показать продукт лицом или накормить общественность сырыми котлетами?
Опции самые что ни на есть репрезентативные. Ровно те, которые рекомендуют авторы инструментов ВСЕМ. С этим спорить бессмысленно.
Бессмысленно спорить с цифрами, но их я здесь не вижу.
Я и не ожидал другого.

В итоге:

— Cat — включено 100% предупреждений
— PVS — включено 70% предупреждений
— Cppcheck — включено 30% предупреждений

Собственно, какой уровень ошибок поставили — такой результат и получили:) И это несмотря на то что я недавно писал, что в cppcheck нет уровней, все ошибки важны, они просто разбиты на категории, а категория error — это баги, в которых анализатор уверен на 100%. По моим тестам cppcheck и CppCat при включении всех предупреждений выдают равное кол-во ошибок.

В предыдущем сравнении хотя бы приводилась корреляция ошибок.
Опубликуйте, пожалуйста, результаты сравнения. Нам очень важны независимые тесты. Буду крайне благодарен.
Результаты есть, но я пока их не обрабатывал. Сейчас будет понятно почему. Я проверял старый как бивень мамонта Xorg, версия, когда ещё вашего анализатора и знать не знали. Ошибок в нём оказалось столько, что хромиум, source sdk, и cryengine даже вместе взятые отдыхают. 1791 ошибок нашёл PVS (сначала было 20 тысяч, но всё-таки я как-то отфильтровал, много предупреждений было из-за препроцессора и несовместимости с Linux) и cppcheck — 2801. Это намного больше, чем то, что описано здесь.
Я хотел бы уточнить. Все таки не ошибок, а сообщений. А сколько из сообщений являются реальными ошибками можно понятно, только проанализировав их все.
Как минимум в PVS-Studio были отключены правила микрооптимизаций и 64-битные диагностики. Да, 64-битные диагностики нужны далеко не всем. Но некоторые покупают PVS-Studio только из-за них.

В PVS-Studio правила оптимизации тоже могут находить ошибки:
if (strlen(str_1) > 4 && strlen(str_1) > 8)
Блог компании PVS-Studio и логично что ваша разработка явилась лучшей.
Найдите изъян. Проекты перечислены. Их можно перепроверить. Пополните таблицы и представьте свои выводы.
Для того, чтобы ПОКАЗАТЬ свои продукты в том или ином ключе мы тратим очень много времени. Все данные выложены. Все отчеты приведены. Ищите «обман и жульничество» ради бога.
Ну строго говоря это автор статьи пытается показать превосходство продуктов вашей компании над аналогами, т.ч. это задача автора — убедить читателей в этом, тем более что он рекламирует свой комерческий продукт. А прикрывать недостатки сравнения и поверхностный «маркетинговый» отчет о проделанной работе фразами в стиле «сперва добейся» типа «мы потратили 170 часов на это сравнение, кто не верит — перепроверьте» — это по меньшей мере не уважение к читателям, если кому-то сильно захочется — он и без ваших советов может сравнить эти продукты, а перепроверять ваши изыскания — ну ни у кого нету лишних пары месяцев…
Анализаторы PVS-Studio и CppCat объективно лучше в диагностических возможностях, чем Cppcat и VS2013. Смиритесь с этим.

Это фраза противоречит сама себе: «он и без ваших советов может сравнить эти продукты, а перепроверять ваши изыскания — ну ни у кого нету лишних пары месяцев». Он не может сравнить, не потратив месяцы. Можно не перепроверять. Проверьте новое. Но быстрее процесс от этого не станет.
Здесь говорится не о проделанной работе, а о подаче материала.
А какая она должна быть? На мой взгляд, мы сделали всё что могли:
  1. Есть подробный отчёт для самостоятельного изучения. Даже фрагменты кода показаны для многих случаев. Не выписан код только для однотипных случаев. При чём, ошибки выписаны для всех анализаторов. Этот же файл разработчики проектов могут использовать, чтобы поправить ошибки.
  2. Есть статья о том, как проводилось сравнение. В ней описано что и почему мы делали. Почему представлены именно эти результаты. Рассмотрено, можно ли доверять этой статье.
  3. И есть сокращенный вариант для быстрого знакомства, который и был опубликован на Хабре. Тем, кому интересны подробности, могут погрузить на один или два уровня ниже.

Извините плохо выразился. Я честно читал все ваши статьи (и я не пишу на С++ ничего уже несколько лет), так как вы всегда хорошо, внятно отвечаете на вопросы в комментариях и более менее объективно подаете материал.
А в этой статье вы в коментариях отвечаете, немного хамовато и часто не на заданные вопросы (я сравниваю с вашими статьями и вашими комментариями, не с вашим коллегой).
Я пал жертвой троллей. Сейчас пообедаю и успокоюсь. Тяжело, просидев многие дни за анализом проектов, получить упрёк, что сравнение поверхностно.
Оговорился. Анализаторы PVS-Studio и CppCat объективно лучше в диагностических возможностях, чем Cppcheck и VS2013.
Да ктобы спорил, что скорей всего комерческие продукты превосходят open source аналог по качеству анализа. Но объективных подтверждений этому лично я в статье не увидел.

Какие противорчеия? Выше и Вы и EvgeniyRyzhkov предлагаете «найти изъян» в Вашем исследовании, которое судя по комментариям заняло ~170 часов… понятное дело, что ни у кого нет ни времени не желания перпроверять Вашу работу, но вот поводов усомниться в объективности результатов достаточно.
А если проверить только один проект за 5 часов, то это будет объективным подтверждением?

Критика должна быть конструктивной. Опишите методику сравнения, которая будет объективным подтверждением и не будет повода усомниться. При чём реальную. А не: «пусть 10 независимых неоплачиваемых экспертов возьмут по проекту и ...» Где их взять то, этих экспертов.
Если конструктивно, то:
1)Судя по разницы во времени работы(114 минут у PVS против 53 у cppcheck), вы явно для cppcheck использовали какой-то light режим работы и анализаторы были в неравных условиях по типам отлавливаемых ошибок. Нужно выставлять более чувствительный режим для cppcheck. Ссылаться на то, что cppcheck не все ошибки правильно классифицирует по типам — не корректно, важен сам факт срабатывания на них. Тем более, если в качестве метрики вы выбираете число найденных ошибок в штуках.
2)Нет кросс-корреляции между выводами анализаторов и нет анализа по типу отлавливаемых ошибок. Вполне вероятно, что cppcheck в таком режиме работы ищет только критические ошибки, в то время как PVS срабатывает и на какихнибудь стилистических ошибках.
Может исследование у вас и было корректным, но цифры в табличках выбраны явно в «маркетинговых» целях и не объективны.
В статье написано, что проверяли в.т.ч. проект Rhino, и что он написан на Java. Ниже сказано, что есть и реализация JS движка на C SpiderMonkey. На чем именно тестировали — на Rhino или SpiderMonkey?
Если честно, даже не знаю, что это такое. Папка с проектом имеет название AOSRHino.
А, так это AOS Rhino Application Server, это совсем другое, он на C++. А я уж было как джавист обрадовался, что вы стали джаву анализировать.
Вы бы исправили, это в статье. Судя по всему aos rhino (http://aobjectserver.codeplex.com/), вообще ничего общего кромя слово rhino в названии не имеет с mozilla rhino, который да полностью написан на java. Я не придираюсь, но вам самим это странно не кажется, что в статье про С++ анализаторы, идет проверка проекта на java (это из вашего описания).
Любопытно, а сколько человеко-часов вы тратите чтобы такое количество статей на хабр генерить…
Хотелось бы уведить проверку исходников php (:
Друзья, на комментарии в стиле: «Вы все делаете не правильно» мы больше не отвечаем, дабы не провоцировать троллей и миллионы одинаковых комментов. Но при этом рады будем вопросам и комментариям по сути, а также по продуктам в целом.

Извините, но не вижу ни единого «вы ВСЁ делаете неправильно».

Нашел только один повторяющийся разными людьми комментарий: вы использовали настройки по-умолчанию. Если ваш продукт находит нечто, чего конкуренты не находят на настройках по-умолчанию, но находят на других настройках — это не преимущество. Конкретный пример.

Наиболее объективным был бы режим «всё включено». Возможно, был резон выбрать меньший по объему проект (что бы всего предупреждений было меньше), но в более жестком режиме его проверить.
Довольно странная реакция на «нехвалебные» комментарии. Авторы статьи тут же их записывают в тролли и потом тут же пишут, что больше на такие каменты отвечать не будут. Учитывая нишевость вашего продукта, я уверен, что ваши статьи заходят почитать как раз занитересованные в предметной области люди и указывают вам на недостатки (с их точки зрения), а вы на них сразу ярлыки вешаете. Это, как минимум, неэтично.
Да вы вообще посмотрите на то как себя там мэнэджмент странно ведёт. То посты о том, что они продают свой продукт фирмам в зависимости от того, насколько фирма успешна (штобы не использовали одну копию много раз). То слезливые посты о том, что Гугл не использует их продукт для проверки своего кода. И в каждом втором посте смертельная обида в комментариях, если кто-то что-то не то скажет. Ну и да, при этом непомерная гордость и уверенность, что они самые крутые и все вокруг не разбираются.
Поучились бы они лучше у МосИгры или Яндекса как корпоративный блог вести. Там очень приятно читать.
Про ценовую дискриминацию с языка сняли.

PVS-Studio — это статический анализатор C/C++ кода (Microsoft Visual Studio и Embarcadero RAD Studio) с простой лицензионной и ценовой политикой, который легко установить и использовать без необходимости развертывания сложного окружения.

пишет в своем профиле г-н Рыжков.

А по факту имеем «вы нам напишите, что у вас за фирма, а мы вам цену придумаем». Я прекрасно понимаю желание пещерных капиталистов продать побольше по разным ценам в разных сегментах, но вы, блин, напишите цены на сайте.
CppCat. Цена $250. Продление $200. Скидки при массовой закупке.
Если CppCat по каким-то причинам тесен — мы готовы обсудить продажу PVS-Studio.
Речь идет о PVS-Studio. Вы готовы здесь назвать цены для команды из
  1. 1-9 разработчиков
  2. 10-30 разработчиков
  3. 31-50 разработчиков
  4. 51-70 разработчиков
?
Ну, строго говоря, это нормальная практика. Klocwork тоже цены не публикует. Но всегда можно связаться с менеджером, договориться. Для такого рода продукта это нормально.
Согласен. Абсолютно нормальная пещерная практика.
Давайте только не будем писать красивых слов про «простую лицензионную и ценовую политику».
А PVS-Studio сколько стоит?) И кстати, как выборочное ценообразование согласуется с нашими законами?
И кстати, как выборочное ценообразование согласуется с нашими законами?


Согласие, есть продукт непротивления сторон.
Да. Хоть это и ужасно неприятная для клиентов практика, когда невозможно узнать цену на продукт, не обратившись на фирму с указанием о себе всей подноготной — но эта практика широко распространена на Западе. Там цена назначается каждому клиенту индивидуально в зависимости от впечатления поставщика о том, сколько можно выжать из данного клиента. Также цена зависит от объема заказа и других факторов. После предложения цены зачастую следует торг. В ходе торга цена может необоснованно повышаться в моменты, которые поставщик счел удобными. На эту возню тратится уйма времени и душевных сил. Но это капитализм как он есть. Привыкайте.
Кстати, а может быть для анализаторов C++-кода сделать отдельный хаб? Или уже имеющийся C++ переименовать :)

А то из 40 последних статей в хабе десять — про анализ кода. Хочется иногда почитать про C++11/14, буст, концепты, тёмную шаблонную магию и пр., а из новинок — очередное «Как %analysis_tool% проверил %project_name% и нашёл %count% ошибок». И ладно бы вместе с проверяемыми проектами менялись ошибки, но и ошибки везде одни и те же — не проверенный на nullptr указатель, копипаст, одиночный цикл, unsigned < 0…

Я-то лично уже наелся анализаторами и количеством ошибок, которые они нашли :) Интересно, кто ещё что думает.
Есть у них свой хаб: «Блог компании PVS-Studio». Но вы посмотрите на количество подписчиков по сравнению с С++…
Интересно было бы также сравнить с выводом clang со всеми ворнингами.
Когда он научится полноценно поддерживать Win проекты — сравним (именно полноценно, а не более-менее).
Daniel Marjamäki написал в форуме небольшой комментарий по поводу этого сравнения. Мне было важно и приятно узнать его мнение. Это автор Cppcheck. Для удобства читателей приведу перевод:

Я прочитал про сравнение. Хочу добавить кое-что насчет Cppcheck:

Согласно цифрам в статье, PVS-Studio сам по себе находит 742 ошибки, а Cppcheck – только 193. Однако пересечение между ними составляет всего 51 ошибку (это в статье не было отражено). Поэтому получается, что если использовать PVS-Studio и Cppcheck совместно, то можно обнаружить 884 ошибки.

Лично я не сомневаюсь насчет того, что PVS-Studio способен находить больше ошибок, чем Cppcheck. И я уверен, что команда Viva64 действительно стремилась провести объективное сравнение. Cppcheck – это любительский проект, и время, которое разработчики могут посвящать ему, очень ограниченно – но при этом мы не стремимся «срезать углы», лишь бы выдать побольше результатов. Я вполне допускаю, что большинство инструментов, над которыми работают штатные программисты на полной ставке, будут обнаруживать больше ошибок, чем Cppcheck.

Конечно, многие пользователи хотели бы использовать только 1 инструмент в процессе работы, и, честно говоря, Cppcheck не очень годится на эту роль. Им больше подойдет какой-нибудь коммерческий продукт. А Cppcheck – инструмент для тех, кому надо найти как можно больший процент реальных ошибок, но при этом не так много, как мог бы найти один коммерческий инструмент.

Эти пользователи также часто полагают, что коммерческий продукт должен по своим диагностикам полностью перекрывать Cppcheck. Однако это ожидание нереалистично. Сравнивать Cppcheck и PVS-Studio – все равно что сравнивать Windows и Linux. Но ведь Windows не является надмножеством Linux, а Linux не является надмножеством Windows.


Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.