Продолжаю бродить по просторам проекта TDengine. Интересный пример косвенного обнаружения ошибки с помощью предупреждения PVS-Studio: V781 The value of the 'size' variable is checked after it was used. Perhaps there is a mistake in program logic. Check lines: 362, 363. osMemory.c 362

Анализатор говорит, что подозрительно проверять значение size после его использования (передачу в функцию realloc). Однако, по задумке автора кода, это нормально. Смысл проверки в следующем: если выделялось более нуля байт, то проверяем, что память удалось выделить. Если выделяли 0 байт, то возврат NULL из функции это ok.

И вроде анализатор выдал предупреждение мимо. Однако, указав на код с запахом, он заставляет сделать его более внимательный обзор. Становится ясно, что код ещё хуже чем казался на первый взгляд. До C23 он плох, но ещё терпим, т. к. всего лишь behavior is implementation defined.

А начиная с C23 это уже вообще UB: if new_size is zero, the behavior is undefined.

GEOS. Красивое :)

PVS-Studio: V557 Array overrun is possible. The '0' index is pointing beyond array bound. string.cpp 54

Приглашаем на вебинар "C++ и неопределённое поведение" 27 февраля в 14:00.

Хотя скорее это будет формат подкаста. Мы пригласили в гости Дмитрия Свиридкина — автора книги "Путеводитель C++ программиста по неопределённому поведению". Обсудим грани, отделяющие корректный C++ код от некорректного, попросим рассказать историю написания книги, поговорим о развитии языка и его будущем.

Пример, как выглядит в коде безопасность для галочки.

Оптимизирующий компилятор вправе удалить последнюю строчку с присваиваниями "l0 = l1 = d[0] = d[1] = 0;", так как с точки зрения языка у неё нет наблюдаемых эффектов. Приватные данные останутся лежать в стековой памяти.

Перед нами разновидность CWE-14. Более распространённый вариант это потенциальной уязвимости – использование "исчезающего" memset.

Хозяйке на заметку. Вместо условных директив компиляции (#if и т.д.), иногда привлекательнее писать просто if, т.к. тогда легче поддерживать весь код в компилируемом состоянии. Т.е. используя #if легко в неподходящий момент получить некомпилируемый код, что проявит себя при смене конфигурации (ключах компилятора).

Но писать if (всегда ложь/истина) тоже плохо по разным соображениям. Например, можно получать верные, но бесполезные предупреждения от компиляторов/анализаторов кода. Поэтому, не забывайте, что существует такая штука как constexpr if statement:

if constexpr ( condition )

Вместо того чтобы прыгнуть, а потом раскрыть парашют, Торопыжка в спешке сначала раскрыл парашют, а потом прыгнул. От этого парашют зацепился за край корзины. Торопыжка запутался ногой в шнурах и повис вниз головой. (С) Приключения Незнайки и его друзей.

В программировании есть аналогичный "антипаттрен торопыжки". О, кстати, может его так стоит и назвать :) Входной указатель в начале разыменовывается, а потом проверяется. Очень частая ситуация.

Классический пример взят из проекта TDengine. Предупреждение PVS-Studio V595 The 'pHandle' pointer was utilized before it was verified against nullptr. Check lines: 2883, 2887. tsort.c 2883

Кстати, на подходе статья "Необходимость статического анализа для РБПО на примере 190 багов в TDengine". До 200 не дотянул, устал выписывать :)

#видеозаписи

Андрей Карпов не первый год рассказывает о поиске ошибок статическим анализом.

Но теперь #БезопаснаяСреда публикует запись доклада, где он зашёл особенно далеко: как найти ненаходимое?

YouTube | VK Видео

Скачать презентацию с сайта SafeCode

AppSec.Hub — платформа DevSecOps от AppSec Solutions, которая автоматизирует внедрение инструментов безопасности и управление процессами безопасной разработки. На вебинаре эксперты продемонстрируют возможности продуктов и покажут, как интегрировать PVS-Studio в AppSec.Hub для создания эффективного конвейера DevSecOps.

Запись доклада: https://pvs-studio.ru/ru/blog/video/11322/