Неделю ничего не писал – отдыхал перед началом сезона конференций и вебинаров и т.д. И раз уж речь зашла про мероприятия, предлагаю вниманию мою сегодняшнюю заметку: SafeCode – конференция, которой мне не хватало.

И заодно недавно опубликованный подкаст с мои участием.

Неформальные процедуры обзоров передавались от человека человеку в общей культуре программирования задолго до того, как информация об этом стала появляться в печатных материалах. Необходимость обзоров была настолько очевидна лучшим программистам, что они редко упоминали об этом в статьях и книгах, тогда как худшие программисты считали, что они настолько хороши, что их работа не нуждается в обзорах.
Дениел Фридмен и Джеральд Вайнеберг (Daniel Freedman and Gerald Weinberg)

Никто не застрахован от простейших ошибок. Перед вами фрагмент кода из одного из самых качественных проектов – LLVM. А ошибка дурацкая: если дошло до вычисления правого операнда ИЛИ, то указатель равен nullptr и он смело разыменовывается. Кстати, наверное в среду как раз проект LLVM возьму для демонстрации работы PVS-Studio на вебинаре УЦ Маском.

Люди, описывающие проектирования ПО как дисциплинированный процесс, тратят много энергии, заставляя всех нас почувствовать себя виноватыми. Мы никогда не станем достаточно структурированными или объектно-ориентированными для достижения нирваны при жизни. Все мы расплачиваемся за первородный грех – изучение Basic в особо впечатлительном возрасте. Но я готов спорить, что большинство из нас проектируют программы лучше, чем кажется пуристам.
Ф. Дж. Плоджер (P. J. Plauger)

Антипаттерн: неправильный способ определения переполнения, которое может возникать при сложении переменных типов unsigned short или переменных типов unsigned char.

При сложении двух переменных типов unsigned short, обе переменные приводятся к типу int. Результат сложения также будет иметь тип int. Поэтому, независимо от того, какие значения будут в переменных x и y, в результате их сложения переполнения никогда не возникнет.

Раньше была диагностика для C++, теперь добавили для C#: V3204.

Во имя эффективности – причём достигается она далеко не всегда – совершается больше компьютерных грехов, чем по любой другой причине, включая банальную глупость.
У.А. Вульф (W.A. Wulf)

Баг, найденный нами в своё время в MySQL. Программист для оптимизации вручную развернул цикл и допустил опечатку. Стоило ли оно того? С этой задачей вполне может справиться оптимизирующий компилятор.

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

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

Например, очень странно если в массиве все числа десятичные, но вот одно захотелось восьмеричным сделать. Ноль, делающий литерал восьмеричным, почти наверняка лишний и вписан для выравнивания столбика чисел.

Никто не умеет писать/проверять функции сравнения :) Даже разработчики LLVM. Сейчас полез с помощью PVS-Studio в код новой версии, а там: V501 There are identical sub-expressions to the left and to the right of the '&&' operator: bits2.is_nan() && bits2.is_nan() Compare.h 23

Парсим С++. 25 октября 12:00.
Приглашаю на бесплатный вебинар на тему разбору C++ кода. Коллега порассуждает о разных видах парсеров и о том, почему в случае С++ всё сложно.

На первые 90% кода приходится первые 90% времени разработки. На оставшиеся 10% кода приходятся другие 90% времени разработки.
Том Каргилл (Tom Cargill)

Слайд из доклада на Innovation Week. Если не брать Python, то анализатор PVS-Studio по-прежнему анализирует код, написанный на самых популярных языках C, C++, Java, C#. Будем продолжать углублять анализ в их направлении. Кстати, про новое: PVS-Studio 7.33: критические ошибки, пользовательские аннотации в C#, поддержка SN-DBS и многое другое.

Очередной баг из проекта LLVM. PVS-Studio выдаёт предупреждение: V522 Dereferencing of the null pointer 'target' might take place. LinalgTransformOps.cpp 2219

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

Если условие if (!target) выполнится, то произойдёт разыменование нулевого указателя: target->getLoc(). Про это анализатор и выдал предупреждение. Но на самом деле, этот указатель никогда не будет нулевым. Однако не спешите делать вывод про недостижимый код.

Ошибка в том, что проверяется не тот указатель. Нужно проверять не target, а tilingOp. Опечатка.