• 0
    Это не противоречие, а невозможность указать один единственный верный способ использования анализатора кода.

    Отключать отдельные диагностики можно. Можно исключать определённые папки с каталогами. И так далее. Подробности описаны в документации. Здесь же была сделана дать некое общее видение ситуации.
    Философия статического анализа кода: три простых шага
  • +2
    И… все. Это в целом путь в никуда, потому что кто будет эти ошибки исправлять, вести учет и прочее? Тот же человек, который иногда его запускает?
    Не соглашусь, что это в путь в никуда. Да, это совершенно неэффективный подход. Но это уже лучше, чем совсем не использовать статический анализ кода. И не важно, кто будет искать и исправлять ошибки. Главное, что будет сделан первый шаг к освоению методологии статического анализа кода.

    Для компромисса, давайте считать, что первый шаг, это знакомство с инструментом. Пусть человеку понравится статический анализ кода, пусть он увидит, что находятся ошибки. Тогда он задумается о необходимости делать это почаще.

    Это если ваш анализатор такое умеет,
    Умеет. И не только PVS-Studio. Такая возможность есть в любом серьезном анализаторе.

    ну и вдобавок, если просто спрятать гору мусора, какой тогда прок от анализатора?
    Никто не говорит, что потом нельзя вернуться к изучению скрытых предупреждений. Это предназначено для облегчения этапа внедрения. Можно начать сразу работать с предупреждениями, выдаваемыми для нового кода, а к старым ошибкам вернуться позже. Как показывает практика, эти старые ошибки менее критичны, иначе приложение бы просто не работало. Т.е. серьезные и явные ошибки уже исправлены и остались те, которые проявляет себя редко или не сильно раздражают пользователей. Эти ошибки конечно тоже стоит править, но с ними пользователи мирятся (возможно годами), а значит они могут и ещё подождать :).

    P.S. Другие дело, если стоит задача устранения потенциальных уязвимостей. Здесь не важно, проявляет себя ошибка при нормальном режиме работы или нет. С точки зрения пользователя, ошибки вообще нет и все работает правильно. Но при этом ошибка может эксплуатироваться при подсовывании некорректных входных данных и про это даже никто не догадывается. Поэтому, в этом случае есть смысл изучать сразу все предупреждения, как новые, так и старые.
    Философия статического анализа кода: три простых шага
  • 0
    Появится. Но пока это только в абстрактном плане.
    Передаю привет разработчикам компании Yandex
  • –4
    Это не имеет практического смысла.
    Передаю привет разработчикам компании Yandex
  • 0
    Ну сфера статических анализаторов, как бы не бедствует: SonarSource, Synopsys (бывший Coverity), Gimpel Software, Rogue Wave Software так далее :).

    И собственно непонятно, прочему речь идёт про «нишу между». clang/gcc/msvc это своего рода статические анализаторы. С этим все просто. Они работают вот так. Мы лучше. С динамическими анализаторами всё тоже просто. Здесь нет конкуренции, а есть взаимное дополнение. В чем-то лучше динамические анализаторы, в чем-то статические. Пример: находим ошибки в Valgrind.
    Передаю привет разработчикам компании Yandex
  • +31
    Шикарный комментарий. Спасибо. Я возьму его в рамочку и буду использовать как собирательный образ заблуждений, касающихся статического анализа кода. И дискутировать на эту тему в статьях и конференциях.
    P.S. Смайлик ставить не буду, так как я совершенно серьезен. И даже напишу на тему этого комментария маленькую статью-ответ.
    Передаю привет разработчикам компании Yandex
  • +1
    class IColumn : private boost::noncopyable
    {
      ....
      /// Name of a Column. It is used in info messages.
      virtual std::string getName() const = 0;
      ....
    };
    
    template <typename T>
    class ColumnVector final : public IColumn
    {
      ....
      std::string getName() const override;
      ....
    };
    
    using ColumnUInt8 = ColumnVector<UInt8>;
    
    Передаю привет разработчикам компании Yandex
  • 0
    В данном случае, думаю еще влияет то, что диагностика V789 весьма свежая и появилась недавно в PVS-Studio 6.16 (28 июня, 2017).
    Передаю привет разработчикам компании Yandex
  • +10
    Когда выполняется «throw Exception» указатель не возможно нулевой, а точно нулевой. Посмотрите повнимательнее на код.
    Передаю привет разработчикам компании Yandex
  • 0
    попробую купить

    Это дело хорошее. Ждем Вас в почте.

    Добавить возможность подключать custom plugins к вашей системе, вообще бы было клёво

    А вот здесь мы всегда были принципиально против и не планируем создавать такую систему. Кажется, что разрабатывать диагностики просто. Но на самом деле, сделать качественную диагностику очень, очень сложно и дорого (трудозатратно). Во-первых, это сложно просто практически. Например, создавая диагностику, мы смотрим как она работает, проверяя более 100 открытых проектов. Это итерационный процесс продолжается, пока мы не добьёмся приемлемых результатов качества. Во-вторых, при создании новых диагностик нам часто приходится добавлять новые интерфейсы в ядро для сбора нужных данных. Невозможно сделать набор интерфейсов и структур данных на все случаи жизни, тем более, что язык Си++ сейчас быстро развивается и появляются новые конструкции. Поэтому не получится сделать какой-то законченный интерфейс. Все равно пользователям будет нахватать то одного, то другого.

    Итого. Сторонние программисты будут тратить много времени и сил (а это дорого), на реализацию собственных диагностик. Плюс будут постоянно отвлекать нас.

    Поэтому всем намного проще, быстрее и дешевле, будет если мы просто реализуем на заказ особую диагностику. И мы временами это делаем (см. диагностики с номером V20xx).

    Хочу еще раз выделить, что такой подход правильный. Незачем делать что-то самим, если можно использовать специалистов. Нет смысла заставлять программистов мыть полы офисе. Это лучше, быстрее и дешевле, сделает специальный человек (уборщица).
    Как перешагнуть через legacy и начать использовать статический анализ кода
  • +1
    Про такой паттерн ошибки мы не подумали. Спасибо.
    27000 ошибок в операционной системе Tizen
  • +1
    #define PI 3.141592655357989 — не ругаемся, так как константа задана очень точно.

    #define ONE_OVER_2PI 0.159154942f — не ругаемся, т.к. анализтор ничего не знает про эту магическую константу. Вот константы, с которыми знаком анализтор: M_E, M_LOG2E, M_LOG10E, M_LN2, M_LN10, M_PI, M_PI_2, M_PI_4, M_1_PI, M_2_PI, M_2_SQRTPI, M_SQRT2, M_SQRT1_2.
    27000 ошибок в операционной системе Tizen
  • +1
    Ключ отправил.
    P.S. Отмечу, что попробовать PVS-Studio for Windows можно и без запроса лицензии. Скачиваем, устанавливаем, проверяем проект и рассматриваем ошибки.
    Борьба с хардкодами при помощи статических анализаторов С#
  • 0
    Кстати, да. Хороший способ контролировать качество кода. Плюс, если есть желание искать не только запахи и частные случаи, можно добавить сторонние плагины. Я думаю вы знаете, что я рекомендую :).
    Борьба с хардкодами при помощи статических анализаторов С#
  • 0
    Идея искать особые случаи понятно. А не было ли желания, использовать ещё и полноценный анализатор кода (например, PVS-Studio) для поиска широкого спектра ошибок? При бурном развитии проекта и росте количества сотрудников, анализатор окажется хорошим помощником по контролю того, что творится в коде.
    Борьба с хардкодами при помощи статических анализаторов С#
  • +2
    Если честно, я так и не понял, что Вы хотели сказать, но одобрил публикацию комментария из уважения к его размеру :).

    За свою практику мы убедились, нет «точно багов». Есть просто баги, а интересны они или нет решает команда разработчиков. Поэтому невозможно выделить ядро (хотя мы и стараемся), которое точно для всех будет ошибка.
    Вот, например, утечка памяти? Ошибка? Для одних — это ОШИБКА! Для других поведение «by design» и предупреждение является ложным срабатыванием.

    Да, и мы ведь не заставляем править все баги. Можно отключить неуместную диагностику и радоваться жизни. Нет времен и на это? Используйте базу разметки и смотрите на предупреждения, относящиеся только к новому коду.
    Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний
  • +1
    В этом коде нет аномалий. Даже я не увидел здесь никаких проблем, пока Вы не рассказали о них. Поэтому и обучить анализатор здесь нечему. Например, это код каких ни будь тестов:

    bool okTest = Test1();
    okTest = okTest && Test2();
    okTest = okTest && Test3();
    okTest = okTest && Test4();
    if (!okTest) Error();
    

    Я подобное встречал и даже сам писал что-то в этом духе. Всё хорошо и часто используется.
    Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний
  • 0
    Обёртка это другое. Хотят именно malloc :).

    Про V779 ничего сказать не могу. Мало данных. Прошу написать, что такое cur.aobj->type. А ещё лучше прислать нам на почту i-файл, мы посмотрим. Выглядит очень странно.
    Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний
  • 0
    Понятие ошибки весьма растяжимое. Особенно при общении с клиентами :). Не будем же мы наставать и не давать отключать предупреждения, ну или по крайней мере скрывать, как это сделать
    Вот смотрите, авторы EFL считают естественным не проверять указатель после malloc. А я тут ещё буду к ним с alloca приставать. :)
    Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний
  • +2
    Да, причём «настройка анализатора» можно писать без кавычек. Способов настройки больше двух, но в целом Вы правы: основная настройка осуществляется за счёт подавления предупреждений, возникающих в творчески реализованных макросах и за счёт отключения диагностик.

    То, что надо отключать диагностики, это нормально. Не все диагностики подходят под определённый стиль написания кода. Например, вот прямо сейчас коллега делает настройку, которая будет указывать анализатору, что функция malloc никогда не вернёт NULL (нет, это не связано с Tizen). Странный подход, но с желанием потенциального клиента спорить мы не будем. Это не совсем тоже, что полное отключение диагностики, но близко.

    Из полного отключения диагностик как раз можно привести упомянутую V505. Кто-то считает каждый килобайт на стеке и такая диагностика просто манна небесная. А для другого бестолковое предупреждение, которое не имеет смысла, так как не было ещё случая, чтобы стековой памяти не хватило.
    Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний
  • 0
    Спасибо. Стараемся.

    Читаемость кода часто действительно становится лучше. На мой взгляд хороший и простой пример, это уделанные проверок перед освобождением указателя. Я описывал это в статье про микрооптимизации (см. V809: The 'if (ptr != NULL)' check can be removed).
    Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний
  • 0
    Я не понимаю эти вопросы. Мы просто делаем мощный, эффективный анализатор кода, который намного превосходит возможности компиляторов. Не вижу смысл обсуждать надо делать или не надо делать «Use of Uninitialized Variable». Мы просто тщательно подходим к этому вопросу и делаем хорошую диагностику. И она обнаруживает ошибки.

    Компиляторы… Так мы использование неинициализированной переменной и в компиляторе можем найти. Вот, например, мы нашли такую ошибку в Clang:
    static Error mapNameAndUniqueName(....) {
      ....
      size_t BytesLeft = IO.maxFieldLength();
      if (HasUniqueName) {
        .....
        if (BytesNeeded > BytesLeft) {
          size_t BytesToDrop = (BytesNeeded - BytesLeft);
          size_t DropN = std::min(N.size(), BytesToDrop / 2);
          size_t DropU = std::min(U.size(), BytesToDrop - DropN);
          ....
        }
      } else {
        size_t BytesNeeded = Name.size() + 1;
        StringRef N = Name;
        if (BytesNeeded > BytesLeft) {
          size_t BytesToDrop = std::min(N.size(), BytesToDrop); // <=
          N = N.drop_back(BytesToDrop);
        }
        error(IO.mapStringZ(N));
      }
      ....
    }
    

    PVS-Studio: V573 Uninitialized variable 'BytesToDrop' was used. The variable was used to initialize itself. typerecordmapping.cpp 73

    Предупреждение «Expression is Always True/False»… Компиляторы… Пфф… :-) Вот, пожалуйста, вновь Clang:
    static bool containsNoDependence(CharMatrix &DepMatrix,
                                     unsigned Row,
                                     unsigned Column) {
      for (unsigned i = 0; i < Column; ++i) {
        if (DepMatrix[Row][i] != '=' || DepMatrix[Row][i] != 'S' ||
            DepMatrix[Row][i] != 'I')
          return false;
      }
      return true;
    }
    

    PVS-Studio. V547 Expression is always true. Probably the '&&' operator should be used here. LoopInterchange.cpp 208

    27000 ошибок в операционной системе Tizen
  • +1
    Если они столь бесполезны — для чего ваш анализатор их выдает?

    Я многократно отмечал в статьях и комментариях, что если мы и делаем диагностики схожие с диагностиками компилятора, то только в том случае, если можем сделать их чем-то лучше/полезнее/удобнее. Просто повторять смысла конечно нет.

    Приведённый пример, был как раз одним из них. Прошу познакомиться с ссылкой, которую я привёл ранее. Там разобрано, как работает диагностика Visual C++ и наша.

    Диагностика V599 PVS-Studio обладает низким процентом false positives и хорошо находит ошибки, на которые ориентирована. А если хочется посмотреть на все классы без виртуальных деструкторов (но содержавших другие виртуальные функции), то можно включить C4265 и наслаждаться.

    Ещё пример.
    #define M1 100
    #define M2 100
    
    int F(int a)
    {
      if (a == M1 || a == M2)
        a = 42;
      return a;
    }
    

    Очень частая ситуация. Числа объявлены через макросы и обозначают разные сущности, но по факту имеют одно и тоже числовое представление. Анализатор Visual C++ выдаёт здесь

    warning C6287: Redundant code: the left and right sub-expressions are identical.

    Что приводит к сильному шуму в некоторых проектах. Мы же учитываем подобные ситуации и специально молчим. Это было одно из первых исключений в диагностике V501 (всего их там сейчас 35).
    27000 ошибок в операционной системе Tizen
  • 0
    Почему диагностика сделана плохо?

    Потому, что на практике она даёт столь много бесполезных сообщений, что её выключили.
    27000 ошибок в операционной системе Tizen
  • 0
    Мы уже пробовали подход с открытыми ценами, причём очень низкими. Подробности.
    27000 ошибок в операционной системе Tizen
  • +1
    Секрета нет. Мы считаем, что так правильно. Наше мнение разделяют другие компании, продающие решения в сфере статического анализа кода.
    27000 ошибок в операционной системе Tizen
  • 0
    На какие «особые стили» компилятор может давать так много шума, что проще выключить предупреждения, считая стиль более ценным?

    Да, такие есть. Имя им – легион.

    Мне сложно сходу приводить примеры. Первое, что вспоминается, это диагностика C4265 (class has virtual functions, but destructor is not virtual), которая отключена по умолчанию. Можно конечно сказать, что диагностика сделана плохо, но формально она звучит правильно. Однако, если используется паттерн примесь (подмешивание), то эта диагностика мешает. Подробности здесь.

    Собственно, можно взять любой большой проект, который не рассчитан на /Wall, скомпилировать его с /Wall и получить массу предупреждений. И вот как только возникнет мысль, что не хочу вот тут править код, а проще выключить предупреждения, так вот это и есть тот самый случай, когда стиль важнее дурацкого предупреждения. :)
    27000 ошибок в операционной системе Tizen
  • +1
    Что интересно, часть ошибок и подозрительных мест, обнаруживаемых статическими анализаторами, успешно обнаруживают и современные компиляторы с выкрученным на максимум уровнем предупреждений.

    Да, это так. Однако помимо того, что статические анализаторы мощнее, есть ещё одно важное отличие. Они больше внимания уделяют борьбе с ложными срабатываниями, пытаясь угадать, используется особый стиль написания кода, или это действительно ошибка.

    Поэтому часто бывает, что диагностика вроде одна и та-же, но компилятор даёт так много шума, что проще её выключить. А анализатор на том же самом коде может давать вполне вменяемый результат, который возможно изучить, найти ошибки, а затем донастроить, чтобы ложных срабатывания вообще пропали.
    27000 ошибок в операционной системе Tizen
  • +4
    А что тут комментрировать… Да, язык ужасно сложный и коварный. Но уж какой есть. Приходится использовать вспомогательные инструменты, такие как PVS-Studio.

    Сам то я только рад такому положению дел. Это приносит нам деньги. :)

    Выдавать предупреждения надо очень аккуратно. И многие предупреждения мы не делаем именно по той причине, что будет слишком много ложных срабатываний (см. Философия статического анализатора PVS-Studio). А когда делаем какие-то диагностики, то стараемся учесть эмпирические нюансы, которые подсказывают есть ошибка или нет.
    Правда ли, что люди пишут безумный код с перекрывающимися побочными эффектами, сохраняя при этом невозмутимость?
  • +4
    Непременно. Рад, что Вы готовы провести такое сравнение. Желаю удачи.
    Поговорим о микрооптимизациях на примере кода Tizen