Open-source проекты, которые мы проверили с помощью PVS-Studio

    PVS-Studio and Open-Source
    Подобная статья уже публиковалась на нашем сайте. Однако, количество проектов увеличивается, и, думаю, будет рационально раз в год обновлять список. Этим и займёмся.

    Мы хорошо относимся к бесплатным open-source проектам. Мы стараемся уведомить авторов проектов о найденных недочётах и при необходимости предоставляем им на время лицензию.


    Ещё хочу напомнить читателям, что у нас появился облегченный анализатор кода под названием CppCat. По диагностикам общего назначения он близок по возможностям к PVS-Studio. Однако он не предназначен для командной работы. Важный момент — пробная версия позволяет полнофункционально использовать CppCat в течение 7 дней. Этого вполне достаточно для проверки среднего Open-Source проекта. Подробнее про CppCat и его отличие от PVS-Studio можно узнать из статьи "Альтернатива PVS-Studio за $250".

    Список open-source проектов, проверенных к настоящему времени с помощью PVS-Studio:

    Наша команда проверяет проекты не безвозмездно. Заметки о найденных ошибках являются рекламой для нас. Мы этого не скрываем. Но, мне кажется, это самая полезная реклама, которую вы когда-либо видели! PVS-Studio действительно помогает open-source сообществу.

    Возможно, вы заметите, что приведённые статьи сильно различаются по объему. Это объяснимо. Например, при написании первой статьи про ReactOS, в анализаторе было реализовано гораздо меньше правил, чем при второй проверке. За это время, анализатор научился находить в несколько раз больше ошибок. Так что подобные статьи будут становиться со временем всё длиннее. Теперь нам приходится пропускать множество неубедительных ошибок, чтобы не превращать статью в справочник.

    На нашем сайте мы также ведем базу найденных ошибок. Думаю, многим из читателей будет любопытно побродить по ней. Но гораздо интересней, что эту базу можно использовать как ресурс для выработки стандартов кодирования, новых рекомендаций в книгах и статьях по программированию. В общем, эта база ждет своего Макконнелла, который сможет вырастить из этого книгу в духе «100 рекомендаций, как не сесть в лужу».
    К сожалению, мы больше не развиваем и не поддерживаем проект CppCat. Вы можете почитать здесь о причинах.
    PVS-Studio 197,53
    Ищем ошибки в C, C++ и C# на Windows и Linux
    Поделиться публикацией
    Комментарии 46
    • +1
      Иллюстрация к этому посту просто мега-крутая.
      • –1
        Спасибо за trinity core :)
        • +17
          Хоть я и не пишу на C/C++, но всегда с удовольствием читаю ваши статьи.
          Некоторые ошибки оказываются действительно очень замысловатыми.
          Да и вообще, подобная модель продвижения продукта мне очень нравится. Побольше бы компаний показывали, как можно использовать их софт в реальных условиях, то есть выводить знакомство за рамки Tutorial/FAQ.
          • –6
            Проприентарное ПО. И нет, это не комплимент.
            • +23
              Конечно не комплимент :D, Пишется-то проприЕТарное
              • –2
                Хоть не «ПроПринтерное» и слава богу.
            • +7
              Ну и?
            • +1
              Кстати, есть проект freeswitch, его не задумывались?
            • +1
              А это, однако же, интересное занятие — с помощью мощного инструмента искать несовершенства и даже откровенные ошибки в чужом коде!

              P.S. Не устану повторять — QT != Qt
              Согласитесь, что cPPcAT или pVs-sTuDiO выглядит не очень? А на кьюте свет клином сошелся и половина игнорирует верное название!
              • 0
                Происходит это (QT/Qt) не со зла. Очень сложно уследить, чтобы люди правильно использовали название.

                P.S. Когда-нибудь я напишу статью со всеми вариантами как люди называют PVS-Studio. Десяток вариантов наберется сразу, еще десяток — если повспоминать и покопаться в почте.
              • +1
                Проверьте ReactOS в третий раз )
                • +2
                  Они (вы) неконтактные какие-то. Раз им (вам) это не нужно, то нам зачем?
                  • +1
                    Я бы так не сказал, ведь почти все найденные баги по результатам прошлых тестов были оперативно устранены.
                    Наш проект развивается, и Ваш инструмент развивается. Интересно какими окажутся результаты теста\проверки в этот раз.
                    • +1
                      Мы пробовали общаться с Брагиным над предмет какого-либо сотрудничества. Общения не вышло.
                      • 0
                        Рискну лишь предположить (всей картины я не знаю), что в Вашем предложении была серьезная коммерческая составляющая.

                        Просто для сравнения, без всякого скрытого упрека скажу, что например Coverty переодически проводят статистический анализ кода ReactOS бесплатно и абсолютно безусловно.
                        • +5
                          Просто для сравнения, у них есть грант на проверку open-source, а у нас нет.
                • 0
                  В той или иной степени использую 9 из перечисленных Open-source проектов. Если качество их кода повышается, я (буду) только благодарен PVS-Studio. В некоторых статьях мелькала информация о предоставлении ключа разработчикам. Вовсе не пользуюсь проприетарным ПО, но за такие шаги готов вас советовать знакомым разработчикам.
                  • 0
                    Советуйте смело, не стесняйтесь! Мы действительно сотрудничаем (в плане ключей и поддержки) с некоторыми разработчиками. Далеко не всеми, конечно, но тем не менее.
                  • 0
                    Нужно проверить код PVS-Studio с помощью PVS-Studio. -)
                  • +1
                    Ждём версии под Linux, работающей без встраивания в IDE.
                  • 0
                    И все-таки, много инспекций реализованы не совсем так, как это сделал бы я. Например, вы ругаетесь на sizeof(x)/sizeof(x[0]), но если x имеет тип LPTSTR или char*, не лучше ли предложить _tcslen()/strlen()? И правильно ли ругаться на это всегда? Ведь для нестроковых массивов этот метод вроде бы приемлем, или нет?
                    • +3
                      Видимо речь идёт о V511 (примеры) или V514 (примеры).

                      Да, для случая работы с «char *» можно рекомендовать использовать strlen(). Однако, это уже второстепенно. Главное, что найдена ошибка. Если она найдена, проблем с правками не будет. Рекомендация использовать strlen() может, как помочь, так и только запутать. Вдруг это массив абстрактных байт.

                      Представьте, что ошибка в заполнении массива вида:
                      typedef unsigned char * BYTE;
                      void SetBlack(BYTE rgba[4])
                      {
                        memset(rgba, 0, sizeof(rgba) / sizeof(rgba[0]);
                      }
                      

                      И тут вдруг мы говорим, что надо использовать strlen(). Люди невнимательны и могут «забанить» такое предупреждение, посчитав, что анализатор сглупил. Ну причём здесь strlnen() какой-то… Мне часто приходится объяснять в почте по поводу разного кода, что это не ложное срабатывание, а действительно ошибка. Люди очень невнимательны при чтении предупреждений и своего кода.

                      Так что неверное анализатору не стоит излишне умничать и пытаться додумать код за программиста.

                      > Ведь для нестроковых массивов этот метод вроде бы приемлем, или нет?

                      Хочу остановится на этом моменте. Да, конечно деление часто приемлемо и предупреждение выдается только для анормальных ситуаций.

                      У меня из головы не выходит один свежих из комментариев к одной из наших статей. Нам написали, что наша беда — «проблема айсберга». Дело в том, что огромная часть нашей работы скрыта от глаз и пользователь видит только сообщения анализатора. Часть которых в добавок ложны. Не имея возможности оценить объем работы, он думает " я такой инструмент за пару недель сделаю, если поработаю как следует". В результате, очень сложно продать инструмент, который «можно сделать за 2 недели». Тут и $250 это много. И поэтому, Вам тяжело продавать.

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

                      Печально, когда кто-то думает, что мы ругаемся на все конструкции sizeof(x)/sizeof(x[0]). Тут и за $25 не продать.

                      Если бы мы так подходили, то проще на каждую непустую строку программы ругаться. Ведь вполне там может быть ошибка. :)

                      Мы проводим колоссальную итерационную работу после написания каждого диагностического правила. Мы проверяем около 80 проектов и смотрим, ложные и полезные сообщения. И решаем задачу, как оставив полезные сообщения, убрать как можно больше ложных. Часто это сложнее, чем придумать и реализовать само диагностическое правило. Да, это не исключает все ложные срабатывания. Но мы очень стараемся. Это и есть подводная часть айсберга.

                      • 0
                        Тот случай, когда комментарий тянет на отдельную статью!
                        • 0
                          Так стоп, я не понял, вот вы пишете что
                          Печально, когда кто-то думает, что мы ругаемся на все конструкции sizeof(x)/sizeof(x[0])
                          Тогда я не понимаю, что конкретно стало критерием для warning’а в тех местах, которые приведены у вас на сайте. Почему именно они, а не другие? Если есть какой-то контекст, мне кажется нужно его показывать. Если это warnings показываются только на типах которые похожи на строки, тогда нелогично утверждать что
                          Рекомендация использовать strlen() может, как помочь, так и только запутать
                          т.к. фактически, вы использовали критерий «строковости» для того чтобы ошибку выловить и показать пользователю, но считаете зазорным упомянуть об этом. Если бы речь шла не о системе анализа а о системе анализ+коррекция, я бы ожидал в этом месте контекстного действия в стиле replace with strlen/_tcslen().

                          Более того, додумывание сценариев для программиста – это именно то, чем PVS занимается в первую очередь т.к. очень много ваших инспекций являются по определению opinionated. Например если я напишу if (x[0] != y[0]) { ... } if (x[1] != y[0]) вы вероятно будете рекоммендовать мне проверить мой код на предметнеправильных индексов (V525) несмотря на то что этот пример — как раз то место где, возможно, не стоило бы додумывать за программиста информацию. Мало ли как я адресую массивы. У меня например многие модели сгенерированы из Excel, там такие инспекции скорее вредят, но я не жалуюсь – false positive всяко лучше чем пропущенная ошибка.

                          Вообщем, резюмируя, мне не очень ясна логика по которой эта инспекция применяется. Расскажите?
                          • +1
                            <зануда=on>Можно почитать документацию. Она всё объясняет и содержит поясняющие примеры: V511, V514.<зануда=off>

                            т.к. фактически, вы использовали критерий «строковости» для того чтобы ошибку выловить и показать пользователю, но считаете зазорным упомянуть об этом.

                            Строки тут вообще ни при чем. Это частный случай. Да, со строками чаще всего проблемы, но всё равно это частный случай.

                            V511
                            (пример из документации)
                            void Foo(float array[3])
                            {
                              size_t n = sizeof(array) / sizeof(array[0]);
                              for (size_t i = 0; i != n; i++)
                                array[i] = 1.0f;
                            }
                            


                            sizeof(array) — вычисляет размер УКАЗАТЕЛЯ, а не массива. Фича Си/Си++. В функцию передаётся не массив из трёх элементов, а просто указатель. То, что в скобках написано [3] вообще ничего не значит. Просто подсказка программисту. Это указатель.

                            Предназначена диагностика для ловли таких ситуаций:
                            ID_INLINE mat3_t::mat3_t( float src[ 3 ][ 3 ] ) {
                              memcpy( mat, src, sizeof( src ) );
                            }
                            


                            Скопируем только 4 байта в Win32 (или 8 в Win64).

                            Тут деление и строки вообще ни при чем.

                            P.S. Но если деление будет, диагностика V511 проявит себя вместе с V514. Вообще, нередко одна ошибка проявляет себя более чем одним предупреждением.

                            V514
                            (пример из примеров ошибок)

                            struct ObjectGroups{
                              componentList objectGrpCompList;
                              int objectGroupId;
                              short objectGrpColor;
                              void write(FILE* file) const;
                            }* objectGroups;
                            
                            void write(FILE* file) const
                            {
                              size_t size = sizeof(objectGroups)/sizeof(ObjectGroups);
                              for(size_t i=0; i<size; ++i)
                              {
                                objectGroups[i].write(file);
                                if(i+1<size) fprintf(file," ");
                              }
                            }
                            


                            Делим размер УКАЗАТЕЛЯ на _неважно что_. Бессмыслица. Здесь вообще 1 получится, так как делим размер указателя на размер указателя

                            Строки опять только частный случай.

                            По поводу доделывания. Да додумывает. Но зачем приплетать strlen(), если диагностики строились вообще из других соображений. V511 — люди не знают про фичу языка. V514 — случайно делят размер указателя на что-то.

                            Очень хорошая дискуссия получилась, которая показывает, что всё намного сложней, чем кажется со стороны. Спасибо. Будем думать, как показать всю глубину наших глубин.
                            • 0
                              А, все, понял. Почему-то показалось что вы против этого целиком. Вообще лучше когда даются хинты «как чинить». Вот если бы там было написано ‘Calculation based on array decayed to pointer; consider replacing with float (&arr)[3]’, вопросов бы не было.
                      • +1
                        Проверьте, пожалуйста, TrueCrypt.
                        • 0
                          Проверяли. Ничего интересного. Буквально пара плохих мест в духе:

                          V517 The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence. Check lines: 7477, 7523. Format tcformat.c 7477
                          
                          BOOL CALLBACK PageDialogProc(....)
                          {
                            ...
                            else if (nCurPageNo == HIDDEN_VOL_HOST_PRE_CIPHER_PAGE)
                            ...
                            else if (nCurPageNo == HIDDEN_VOL_HOST_PRE_CIPHER_PAGE)
                            ...
                          }
                          
                          
                          V547 Expression 'fileDataEndPos < 0' is always false. Unsigned type value is never < 0. Setup selfextract.c 551
                          
                          BOOL SelfExtractInMemory (char *path)
                          {
                            unsigned int fileDataEndPos = 0;
                            ...
                            if (fileDataEndPos < 0)
                            {
                              Error ("CANNOT_READ_FROM_PACKAGE");
                              return FALSE;
                            }
                            ...
                          }
                          
                        • НЛО прилетело и опубликовало эту надпись здесь
                        • +1
                          Было бы здорово, если бы вы смогли проверить OpenMW
                          • 0
                            Проверьте библиотеку Qt. При их огромных объемах кода наверняка найдете кучу ошибок.
                            • 0
                              Не очень понятно, что такое «проверьте Qt». Нет же одного солюшена, который бы назывался Qt.

                              Это если игнорировать указанную в списке статью про проверку Qt :-).
                              • 0
                                Под Qt понимается библиотека Qt. К тому же вы проверяли 4 версию-которая уже не очень популярна. Лучше 5 версию проверьте
                            • +1
                              Проверьте bitcoin :D
                            • 0
                              Проверьте пожалуйста и Threading Building Blocks (https://www.threadingbuildingblocks.org/download#stable-releases). Полагаю в Intel проверяют код своим статическим анализатором кода. Будет интересно узнать результаты.
                              • 0
                                Некоторые Интеловские проекты есть в списке выше. Ошибок хватает :-).
                              • +2
                                А nginx проверяли? :-)

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

                                Самое читаемое