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

Решил кратко сформулировать 3 причины, по которым embedded-разработчикам полезны инструменты статического анализа кода программ.

PVS-Studio — это статический анализатор кода для поиска ошибок и потенциальных уязвимостей в коде программ на языке C, C++ и C#. Мы давно радуем читателей нашего блога проверкой открытых проектов и разбором найденных ошибок. Наши статьи имеют потенциал стать более интересными, так как анализатор научился проверять код встроенных устройств. Мы поддержали несколько ARM-компиляторов, про которые подробнее вы узнаете из статьи. Ошибки во встроенных устройствах и роботах могут быть более зрелищными, чем в прикладных программах. Ошибка во встроенном устройстве — это не просто падение/зависание программы или неправильная картинка. Это сошедший с ума Wi-Fi-чайник, который будет кипятить воду, пока она не выкипит и не сработает термопредохранитель. В общем, с ошибками в мире embedded-систем всё обстоит куда интереснее и страшнее.

Мне кажется, бунт роботов не близок. Я начал писать статью про то, что наша команда приступила к адаптации анализатора кода PVS-Studio для нужд Embedded-разработчиков. Для начала мы поддержали KEIL и IAR. Посмотрев на ошибки в некоторых проектах для встроенных устройств, я полон чувств, которыми хочу поделиться. Проще всего это будет сделать, показав пару картинок и пару примеров ошибок.

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

Как я писал в вводной статье, просматривая отчёт, выданный анализатором PVS-Studio, я заметил около 250 ошибок в проекте Chromium и использованных в нём библиотеках. Отчёт я смотрел достаточно бегло, поэтому, на самом деле, ошибок можно найти намного больше.

После вводной статьи я написал еще 6, где рассматривал различные паттерны ошибок. Писал я эти статьи, писал, и всё равно, у меня остаётся около 70 примеров ошибок. Сделать на основании оставшихся багов статьи на разные темы я затрудняюсь. Возможно, я устал. Впрочем, есть и другая причина — меня ждёт отчёт о проверке XNU и мне не терпится им позаниматься.

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

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

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

На самом деле, причиной уязвимости может стать ошибка почти любого типа, даже обыкновенная опечатка. Собственно, если найденная ошибка классифицируется согласно Common Weakness Enumeration, то значит она является потенциальной уязвимостью.

Анализатор PVS-Studio, начиная с версии 6.21, научился классифицировать найденные ошибки согласно Common Weakness Enumeration и назначать им соответствующий CWE ID.

Предлагаем вашему вниманию цикл статей, посвященных рекомендациям по написанию качественного кода на примере ошибок, найденных в проекте Chromium. Это четвёртая часть, которая будет посвящена проблеме опечаток и написанию кода с помощью «Copy-Paste метода».

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

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

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

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

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

Многие годы я изучал ошибки в программах и сейчас могу с уверенностью заявить, что в C, а вслед за ним и в C++, оператор switch сделан неправильно. Я понимаю, что возможность не писать break, сделанная, чтобы передать управление дальше, позволяет писать изящные алгоритмы. Но всё равно огромное количество ошибок убедило меня, что был выбран неправильный подход. Понятно, что теперь уже поздно. Просто хотелось сказать, что правильным решением было бы обязательно писать слово break или обратное ключевое слово, например, fallthrough. Сколько бы сил, времени и денег было сэкономлено. Конечно, этот недостаток не сравнится с Null References: The Billion Dollar Mistake, но всё равно большой ляп.

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

Господа программисты, с функцией memset надо что-то делать в C++ программах! Вернее, даже сразу понятно что делать — её надо прекратить использовать. В своё время я написал статью "Самая опасная функция в мире С/С++". Я думаю, несложно догадаться, что речь в статье идёт как раз о memset.

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

Предыстория

Меня зовут Андрей Карпов, и я являюсь евангелистом статического анализа в целом и инструмента статического анализа PVS-Studio в частности. Впрочем, термин «технический евангелист» уже устаревает и на его смену приходит «developer advocate».

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

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

Приближается 2018 год и пора подумать о новых направлениях развития нашего статического анализатора PVS-Studio. Сейчас наибольший интерес для нас представляет поддержка языка Java. Дополнительно мы рассматриваем возможность поддержки языка IBM RPG. Не менее интересно развить анализ C, C++ C# кода в направлении выявления потенциальных уязвимостей. Ещё нам хочется поддержать анализ C и C++ кода на платформе macOS, и, наконец, доделать поддержку компиляторов от компаний Keil и IAR. Никуда мы не денемся и от поддержки стандарта MISRA. Перечислено много, и на всё одного 2018 года нам не хватит. Поэтому давайте вместе с нами пообсуждаем наши планы и выберем самые приоритетные направления.

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

Комментарии

Комментарии написаны к статье "Передаю привет разработчикам компании Yandex". Первый находится здесь. Процитирую его:

Все эти анализаторы кроме пользы добавляют гемор в виде замедления билда, ложных срабатываний, информационного шума и ложного чувства безопасности. Для себя я решил, что профессионалам чем меньше таких тулзов тем лучше — гемор легко перевешивает пользу. А нубасам такое тоже особо не поможет — им бы учиться писать юнит тесты, а не тратить время на затыкание варнингов. Возможно, в Яндексе думают так же. Хотя если тесты гонять перед релизом, то гемор будет меньше, и можно будет выцедить нормальное соотношение время/ошибки, так что хз. Дисклеймер: PVS-Studio я не пробовал.

Нас часто спрашивают, умеет ли статический анализатор кода PVS-Studio выявлять утечки памяти (memory leaks). Чтобы много раз не писать похожие тексты в письмах, мы решили дать подробный ответ в блоге. Да, PVS-Studio умеет выявлять утечки памяти и других ресурсов. Для этого в PVS-Studio реализовано несколько диагностик и в статье будут продемонстрированы примеры обнаружения ошибок в реальных проектах.

Научное сообщество практически незнакомо со статическим анализатором кода PVS-Studio. 30 ноября и 1 декабря состоится мероприятие «Технологии анализа, моделирования и трансформации программ» в рамках открытой конференции ИСП РАН им. В.П. Иванникова. Я уверен, что это одно из самых тематичных для нас мероприятий, где новая аудитория могла бы узнать о существовании и возможностях анализатора PVS-Studio. На мой взгляд, наиболее подходящим для этого мог стать доклад, касающийся поиска ошибок в операционной системе Tizen. К сожалению, доклад получил отрицательные отзывы рецензентов и не будет включен в программу конференции. Тем не менее, пользуясь случаем, подведу итоги наших исследований, касающихся кода Tizen.

Мои читатели попросили сравнить проекты Manticore и Sphinx с точки зрения качества кода. Я могу сделать это только одним освоенным мною способом — проверить проекты с помощью статического анализатора PVS-Studio и посчитать плотность ошибок в коде. Итак, я проверил C и C++ код в этих проектах и, на мой взгляд, качество кода Manticore выше, чем качество кода Sphinx. Естественно, это очень узкий взгляд, и я не претендую на достоверность своего исследования. Однако меня попросили, и я сделал сравнение так, как умею.

Сайт Pinguem.ru и команда PVS-Studio организуют конкурс, посвященный повышению качества открытого программного обеспечения. Для победы в конкурсе необходимо исправить как можно больше ошибок в одном или нескольких открытых проектах. Ошибки должны быть обнаружены с помощью статического анализатора кода PVS-Studio. Главный приз: консоль PlayStation 4 Pro.

Правила конкурса на сайте Pinguem.ru. Участвовать в конкурсе.