Andrey2008
+9
NaN всегда неравен NaN.
Andrey2008
+1
Моё новое интересное исследование: Зло живёт в функциях сравнения.
Andrey2008
0
А какая нам разница, как с Tizen в России? Главное, что в целом сейчас эта ОС активно развивается и продвигается.

P.S. Команда PVS-Studio готова поработать над проектом Tizen (открытое письмо)
Andrey2008
–1
Думаю, никакой проблемы нет. Точечные предупреждения размечаются как //-V501 и их легко найти. Макросы да, размечаются так //-V:qqq:501, но так ли много будет таких случаев? Тем более что такой комментарий логично написать рядом с макросом и соответственно его можно будет легко найти, когда захочется продемонстрировать кому-то подавление предупреждение в этом самом макросе.

Если вдруг надо подавлять много предупреждений в разных макросах или нельзя менять заголовочные файлы, то можно собрать всё это в pvsconfig файлы. См. в документации о подавлении ложных срабатываний раздел «Массовое подавление ложных предупреждений с помощью файлов конфигурации диагностик pvsconfig». Соответственно, раз всё собрано в одном месте, опять-таки будет легко найти всё что, нужно.
Andrey2008
0
Пока не поддерживается, но в todo записано. Про собственные форматы символов анализатор ничего не знает. Если пометить, что это аналог printf, то анализатор будет ругаться на нестандартные управляющие символы.
Andrey2008
0
И что-бы вообще отключать диагностику: //-V::501
Andrey2008
0
Что-бы можно было писать: -V:Q_ASSERT:501,502,555
Andrey2008
0
Уже отвтили, но на всякий случай ссылка: Подавление ложных предупреждений (см. Подавление ложных предупреждений в С/С++ макросах (#define) и для других фрагментов кода).
Andrey2008
+1
Да, такоей механизм уже есть. См. описание диагностики V576 (раздел «Дополнительные возможности»).
Andrey2008
+2
Да, но без потери производительности. В любой момент можно использовтаь те технологии, чтобы получить эффективность Си.
Andrey2008
0
А вот я добрался и до Tizen. Путь будет длинным, но интересным. Ведь как гласит реклама:
Тайзен — единственная сертифицированная в России операционная система для построения эффективной платформы мобильных решений для государственных и корпоративных предприятий.
А что внутри? Видимо всё как обычно:

full_path = (char *)alloca(PATH_MAX);
....
free(full_path);


Будет статья от команды PVS-Studio, будет! :)
Andrey2008
+2
Эх, если бы это действительно было так и мы были всем известны… :(

Вы преувеличиваете. Просто так совпало, что Вы присутствуете на тех же площадках, что и мы. Вот и создаётся впечатление, что мы везде. У нас на эту тему даже заметка есть: "Ох, опять они со своим PVS-Studio. Везде они...".

В реальности же, мы никому не знакомы, даже в России. Например, приезжаешь на семинар в МЦСТ. Собралось около 25 программистов. Из них про PVS-Studio слышали около двух человек. Вот такие суровые реалии…
Andrey2008
0
И здесь молчит. Хочу сказать, что мне не нравится подобные рассуждения и эксперименты на основе подобных тестов. Прошу почитать: Почему я не люблю синтетические тесты.
Andrey2008
+1
Анализтор промолчал в обоих случаях. Во втором случае стоит что-то сказать, взял на карандашь. Спасибо.
Andrey2008
0
На это автор кода может возразить

Может. Это его право. Задача статического анализтора указать на подозрительный код. Задача программиста оценить это сообщение и предпринять меры, если они нужны или подавить предупреждение.
Andrey2008
+3
Освобождение памяти отсутствует сознательно. Удаление сотен тысяч отдельных объектов это медленно. Впрочем, их можно почистить быстрее, так как для их выделения используется свой собственный менеджер памяти. Но даже он отключен, так как всё равно это пустая потеря времени.

Механизм освобождения в менеджере памяти используется только при прогоне юнит-тестов, чтобы не сжирать слишком много памяти при проверке различных тестовых *.i файлов. В случае же работы в пользовательском режиме память освобождает операционная система, завершая процесс. Такой подход экономит порядка 0.1 секунду (значение приблизительное, давно не замерял время) на запуск. Проверили 1000 файлов и вот уже экономия в 100 секунд: приятно.
Andrey2008
0
Пока не пробовали. Там ожидаемо будет 100500 утечек памяти, так как узлы дерева не удаляется в процессе работы, так как построенное дерево используется до конца работы программы. А в конце просто завершить программу, без предварительного удаления дерева. Этакая оптимизация скорости работы.
Andrey2008
0
Я не обещал, что такой анализатор не будет давать ложно позитивных и ложно негативных срабатываний. :) Просто он будет работать чуть тщательнее, чем обычно.
Andrey2008
+3
Можно ввести ограничение: если анализатор уже год анализирует одну функцию, то предупредить, что возможен вечный цикл. Ведь я не говорил, что такой теоретический анализатор не может выдать ложное срабатывание. :)
Andrey2008
0
Да, мы подумаем про это.
Andrey2008
0
Для этого совершенно не обязательно использовать PVS-Studio
Это всё лирика. :) Обязательно, не обязательно, а ошибка найдена именно с помощью PVS-Studio. Как и ещё 11037 ошибок. О чем это говорит?

  1. Анализатором PVS-Studio для поиска многих ошибок пользоваться удобнее и приятнее, чем компиляторами. У компиляторов много ложных срабатываний, неудобный способ фильтрации, плохая документация и т.д.
  2. Анализатор PVS-Studio мощнее. Более того, процесс работы над ядром анализатора только усиливается.

И за это мы получаем деньги.
И ещё мы очень скромные, да.
Andrey2008
+1
Выдвигая такие условия, вы достаточно ясно говорите своей аудитории: «На самом деле, мы не хотим, чтобы вы использовали наш анализатор бесплатно для чего-то серьёзного — поэтому или идите купите лицензию, или превратите свой проект в нашу рекламную вывеску.»

Да, так и задумано. Не вижу ничего в этом плохого или нечестного.

У нас возможностей запутаться в индексах просто море, но мы возлагаем большие надежды на ассерты и valgrind.

Возлагать то можно, но лучше, когда разные инструменты дополняют друг друга. Тот-же valgrind не видит то, что замечает PVS-Studio. Ну-ка, что это у него такое вот тут в коде:
      } else {
         goto no_match; //ATC
         cc = iselCondCode( env, guard );
      }

Ай, это же мёртвый код. Фи, нехорошо… :) В пятницу будет статья про проверку valgrind.
Andrey2008
0
Это защита от коммерческих проектов с открытым исходным кодом.

И с закрытым тоже. :) Не каждый менеджер будет рад видеть в проекте компании такие комментарии.
Andrey2008
0
P.S. Не нравится в своём собственном ответе, что я о статическом анализе сказал как только о приятном дополнении в виде повышения качества кода. Но ведь очень важно, что выявление ошибок на ранних этапах, это ещё и большая экономия времени на отладку и тестирование. Т.е. ошибка может быть найдена сразу и исправлена. А если её будет находить дополнительно нанятый человек, то это целый процесс, где будет участвовать тестировщик, программист, багтрекер, отладчик и так далее. К сожалению, тут посчитать вообще очень сложно.
Andrey2008
–2
Вопрос — что дешевле, купить PVS или на эти деньги нанять пару лишних тестировщиков

Цена анализатора по сравнению стоимостью зарплаты команды программистов пренебрежимо мала. Так что не понятно, что тут собственно высчитывать. Анализ кода (т.е. контроль его качества) или нужен, или не нужен.

Я даже про тестировщиков не понимаю. Возьмём двух тестировщиков с зарплатой скажем в 40000р. В год на них будет потрачено 40*2*12=960 т.р. Это ещё без налогов. А если добавить траты на рабочие места, аренду, бух. сопровождение и т.д., то в итоге эти два тестировщика за год съедят около 1,5 млн. рублей. Эти траты уже в несколько раз больше, чем стоимость базовой версии PVS-Studio.

Поэтому я и говорю, Вам или нужен дополнительный контроль качества кода или не нужен. Статический анализ, это ответ на вопрос «что мы ещё можем сделать для улучшения качества проекта?». Естественно на него стоит отвечать только тогда, когда уже есть и квалифицированные программисты и тестировщики. А если их нет, тут уж не до статического анализа… :)
Andrey2008
+4
Это неправильный подход. Ценность статического анализа не в разовом запуске, а в его регулярном использовании. При регулярных запусках многие ошибки можно устранять на самых ранних этапах, а не когда о них сообщают пользователи. Например, вот человек в ответ на мой твит пишет:

I reported similar bug in MFC, they have leaked some tooltips or whatnot in function CMFCToolBar::UpdateTooltips. I found it by umdh tool.

И зачем так сложно, когда такую ошибку можно было бы найти самим разработчикам библиотек сразу после написания кода?

Отсюда следует, что фраза «не вижу, что найденные вами ошибки оправдывают те килобаксы, которые стоит PVS-Studio», логически неверная. Проведу аналогию с предупреждениями компилятора. Представим, что есть работающий проект, который разрабатывается с отключенными предупреждениями компилятора. Включаем их и смотрим. Есть ли смысл тратить и дальше время на их изучение, или лучше опять их выключить? Вряд ли предупреждения укажут на серьезную ошибку, проект ведь отлажен и работает. По предложенной Вами логике предупреждения надо отключить, так как они не показали свою ценность, не найдя фатальные ошибки.

Andrey2008
+1
С замечанием согласен.
Andrey2008
+3
В шаблонах особенно анализировать нечего. В том смысле, там куда не пойди везде неизвестные типы. В связи с этим анализ крайне ограничен в возможностях, потому что, когда нельзя вывести тип, лучше молчать.
Поясню на примере. Выход за границу массива:
template <class T> class Foo
{
  void F()
  {
    T a[10];
    for (T i = 0; i != 11; ++i)
      a[i] = i;
  }
};

Анализатор PVS-Studio здесь молчит. Ибо не понятно, что такое это T, какой тип массива и какой тип у индекса 'i'.

Но стоит добавить ниже:
void Q()
{
  Foo<int> x;
}


И анализатор PVS-Studio радостно выдаст предупреждение:

V557 Instantiate Foo <int>: Array overrun is possible. The value of 'i' index could reach 10. Level: 2

Так что не стоит ожидать от анализатора чудес, если просто напихать в проект заголовочных файлов с шаблонными классами и функциями (что собственно я и сделал).
Andrey2008
+1
Использование ReSharper не мешает находить нам ошибки в C# проектах.

Что касается C++ то, я заявляю, что PVS-Studio лучше многих анализаторов кода (ReSharper, Cppcheck, ...). Наступаем на пятки и в ближайшее время превзойдём по многим направлениям Coverity и Klocwork. Я знаю, что PVS-Studio крут и мы регулярно это показываем на практике. Если кто-то хочет опровергнуть, пусть попробует доказать обратное.
Andrey2008
0
решарпер
Не стоит смешивать статические анализаторы кода и productivity tools. Статический анализ это подробная документация по всем диагностикам, поддержка и консультирование, это интеграция с IncrediBuild, это Standalone, это инструменты интеграции в большой проект (например, база разметки сообщений), отслеживание запусков компилятора (CLMonitoring), рассылка писем и т.д.
Andrey2008
–1
Да. Опечатался:

Да и вообще, никто не обещал, что переполнение будет знаковым.
Andrey2008
0
А кто те многие, которые выступают против статического анализа?
Я видел их в комментария, в почте. Но я никогда не собирал ссылки на такие дискуссии, поэтому не могу сейчас достать список «100 примеров». В общем с пруфами затруднение и даже как поискать не знаю. С ходу только вспомнилась заметка "Народ против PVS-Studio: дубль первый" с выводом в конце: не следует полагаться на анализаторы, скорее нужно просто повысить свой уровень профессионализма. Формально вывод правильный, но при разборе статьи выясняется, что автор просто не разобрался в вопросе.