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

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

Например, помимо стандартных групп диагностик вроде General Analysis, 64-bit analysis или Optimization у нас в PVS-Studio есть группа под названием Customer's Specific. Туда попадают диагностики, которые нужны нашим клиентам, но которые не подходят под прочие группы диагностик. Выражаясь более художественно можно сказать так. Группа диагностик Customer's Specific является эрогенной зонной нашего продукта. Если ее потрогать (добавить туда какую-то диагностику), то клиенту станет очень приятно. Естественно такой подход к развитию продукта и продаже надо применять очень осторожно, так как конечный клиент не обладает полным видением продукта и не имеет представления о том, куда продукт развивается.

Еще нам нравится, как работает предпродажная команда в компании Coverity. Мы конечно не уверены в этом на 100%, но нам кажется, что они работают примерно так. Если появляется потенциальный клиент, то к нему вылетает спецназ на вертолете, который на месте настраивает окружение, запускает анализатор, внимательно работает со списком диагностических сообщений и т.п. В завершении всего этого для потенциального клиента делается ПРЕЗЕНТАЦИЯ (!), в которой клиенту рассказывают про ошибки, найденные в его проекте, и говорят, что нужно делать, чтобы их не было (купить инструмент, ага). Почему они так делают? Хороший вопрос! Наверное, они считают, что разработчик инструмента может намного более качественно им пользоваться. У него больше опыта, он легче определяет ложные срабатывания и умеет их отсеивать, у него набит глаз на реальные ошибки и он их не пропустит. Это значит, что потенциальные клиенты получат намного больше ярких впечатлений от первого знакомства с продуктом, чем если бы они сами потыкали в нём кнопки.

И мы подумали – а что если нам действовать также как Coverity? К сожалению, спецназ на вертолете мы пока выслать не можем. Но что если мы попробуем проверить код потенциальных клиентов и сами найдем реальные программные ошибки в их проектах? Да еще и сделаем презентацию ну или хотя бы отчет о найденных проблемах? Наверняка тогда больше потенциальных пользователей захочет купить наш инструмент! Но, естественно, никто нам чужой код на сторону не даст, поэтому решили попробовать проверять код потенциальных клиентов в удаленном режиме, подключаясь к их компьютерам из своего офиса. Кому такое интересно – читаем далее.

Только что, я сел и проверил проект VirtualDub с помощью PVS-Studio. Выбор был случаен. Я считаю, самое главное регулярно проверять/перепроверять различные проекты, чтобы показать, как развивается анализатор кода PVS-Studio. А какой проект будет проверен, не так важно. Ошибки есть везде. Проект VirtualDub мы уже проверяли в 2011 году, но тогда почти ничего интересного не нашлось. Вот я и решил посмотреть, как обстоят дела, спустя 2 года.

Я занимаюсь созданием анализатора PVS-Studio, выявляющего ошибки в исходном коде приложений на языке C/C++/C++0x. В связи с этим мне приходится просматривать большой объем исходного кода различных приложений, где с помощью PVS-Studio были обнаружены подозрительные участки кода. У меня накопилось достаточно примеров, в которых хорошо видно, когда ошибка появилась на свет из-за копирования участка кода и его модификации. Конечно, это не новая идея, что использовать Copy-Paste при программировании плохо. Однако попробуем не отделываться рекомендацией «не копируйте код» и подойдем к этой теме более внимательно.

Встреча в Кёльне прошла, стандарт C++20 приведён к более или менее законченному виду (по крайней мере до появления особых примечаний), и я хотел бы рассказать об одном из грядущих нововведений. Речь пойдёт о механизме, который обычно называют operator<=> (стандарт определяет его как «оператор трёхстороннего сравнения», но у него есть неформальное прозвище «космический корабль»), однако я считаю, что область его применения гораздо шире.

У нас не просто будет новый оператор — семантика сравнений претерпит существенные изменения на уровне самого языка.

Я регулярно проверяю различные открытые проекты, чтобы продемонстрировать возможности статического анализатора кода PVS-Studio (C, C++, C#). Настало время компилятора GCC. Бесспорно, GCC — это очень качественный и оттестированный проект, поэтому найти в нём хотя бы несколько ошибок уже большое достижение для любого инструмента. К моей радости, PVS-Studio справился с этой задачей. Никто не застрахован от опечаток и невнимательности. Именно поэтому PVS-Studio может стать вашей дополнительной линией обороны на фронте бесконечной войны с багами.

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

Чуть больше года назад, мы решили провести эксперимент и выпустить альтернативу статического анализатора кода PVS-Studio для маленьких команд и индивидуальных разработчиков. Так появился очень недорогой анализатор под названием CppCat. Сейчас можно подвести итоги этого эксперимента и признать, что он оказался неудачным. За срок чуть более года он принёс приблизительно столько денег, сколько было потрачено на его разработку, продвижение и поддержку. Таким образом проект убыточен. Ведь потраченное время (самый ценный ресурс) мы могли бы использовать для совершенствования PVS-Studio. Мы вынуждены закрыть проект CppCat и сосредоточиться на PVS-Studio. Надеюсь, читателям будет интересен чужой опыт в реализации новой бизнес идеи. Негативный опыт — это тоже полезный опыт.

Предлагаем вниманию программистов новый инструмент для поиска ошибок в исходном коде приложений на языке Си/Си++. В рамках анализатора PVS-Studio реализован новый набор правил общего назначения. Эта функциональность на данный момент является бесплатной. Вы можете скачать PVS-Studio по адресу http://www.viva64.com/ru/pvs-studio-download/.

В статье кратко рассказывается о новых возможностях PVS-Studio. На примере статического анализа исходного кода проекта TortoiseSVN будет продемонстрировано использование новых диагностических возможностей.

Свершилось! Сегодня мы выпустили публичную версию анализатора PVS-Studio для Linux. Теперь разработчики Linux приложений получат новое мощное оружие для борьбы с багами в коде. Призываем разнести эту новость по миру. Расскажите своим коллегам по работе, напишите в Twitter и Facebook! Да будут программы надёжней и стабильней!

Около года назад мы смогли проверить ядро Linux. Это была одна из самых обсуждаемых статей о проверке open-source проекта за всё время. Предложения обратить внимание и на FreeBSD тогда активно поступали, но только сейчас появилось достаточно времени, чтобы это сделать.

Я временами бываю озадачен, рассматривая ошибки в очередном программном проекте. Многие из этих ошибок живут в проектах годами. Смотришь на сотню ляпов в коде и удивляешься, как программа вообще работает. И ведь как-то работает. Ей даже пользуются. Причем, я говорю не о коде, рисующем покемона в игре. А, например, о математических библиотеках. Да, вы верно догадались. В этой статье пойдет речь о проверке кода математической библиотеки Scilab.

Есть такой миф, что открытое программное обеспечение более качественное и безопасное, чем закрытое. Много раз это обоснованно ставилось под сомнение. Существует примеры, когда в открытом коде находили эпичные уязвимости, которые скрывались от разработчиков и пользователей долгие годы. Я считаю, что качество проекта зависит от того, как руководители разработки построили процесс и какие методологии/инструменты используются, а не от того, открыт или закрыт проект.

Тем не менее по-прежнему живо поверье, что открытый проект — это хорошо. Мол, тысячи глаз людей могут изучать код, и кто-то да заметит ошибку. Мысль развивать не буду, думаю, вы понимаете, что я имею в виду.

Это заметка о любви. О любви статического анализатора кода PVS-Studio к замечательной открытой операционной системе Linux. Эта любовь молода, трогательная и ранима. Этой любви нужно помочь укрепиться. Вы поможете, если заранее запишитесь в добровольцы для тестирования beta-версии PVS-Studio for Linux.

PHP — скриптовый язык программирования общего назначения, интенсивно применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов.

В случае с компиляторами и интерпретаторами к исходному коду и тестированию, как правило, предъявляются повышенные требования качества и надёжности. Тем не менее, в исходном коде интерпретатора PHP нашлись подозрительные места.

В данной статье будут рассмотрены результаты проверки интерпретатора PHP, полученные с помощью PVS-Studio 5.18.

Сегодня важный день – после 28 релизов шестой версии мы выпускаем PVS-Studio 7.00, где ключевым новшеством является поддержка языка Java. Однако за 2018 год накопилось много других важных изменений, касающихся С++, С#, инфраструктуры и поддержки стандартов кодирования. Поэтому предлагаем вашему вниманию заметку, которая обобщает основные изменения, произошедшие в PVS-Studio за последнее время.

Мы закончили сравнивать статические анализаторы кода Cppcheck, PVS-Studio и анализатор встроенный в Visual Studio 2013. В ходе этого было проверено более 10 открытых проектов. И про некоторые из них можно написать статьи. Вот очередная такая статья о результатах проверки проекта CryEngine 3 SDK.

В списке вопросов, которые всегда задают нам после прочтения наших статей есть вопрос: «А вы проверяете код своего анализатора им самим?». И дается ответ в том ключе, что у нас всегда проверяется код во время написания с помощью режима инкрементального анализа (проверки файлов сразу после компиляции). А также запускаются ночные проверки для всего кода. И в связи с этим мы, к сожалению (ирония), никогда не сможем написать статью про ошибки в наших программных продуктах.

Однако сегодня – именно статья про одну нашу ошибку и про то, сколько она нам стоила. Заинтриговал?

Предлагаем вашему вниманию цикл статей, посвященных рекомендациям по написанию качественного кода на примере ошибок, найденных в проекте Chromium. Это шестая часть, которая будет посвящена функции malloc. Вернее, тому, почему следует обязательно проверять указатель, возвращаемый этой функцией. Скорее всего, вы не догадываетесь, какой подвох связан с malloc, потому рекомендуем познакомиться с этой статьей.

Примечание. В статье под функцией malloc часто будет подразумеваться, что речь идёт не только именно об этой функции, но и о calloc, realloc, _aligned_malloc, _recalloc, strdup и так далее. Не хочется загромождать текст статьи, постоянно повторяя названия всех этих функций. Общее у них то, что они могут вернуть нулевой указатель.