Эта статья могла бы получить название "Как PVS-Studio защищает от поспешных правок кода, пример N7". Однако так именовать статьи становится скучновато. Поэтому сейчас вы узнаете, причём здесь Фредди Крюгер.

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

В общем, иногда мы торопимся при написании кода. Плюс ещё и невнимательны, когда код кажется простым. Мне кажется, перед нами ошибка, как раз возникшая из-за спешки и отсутствия последующей проверки, ведь код такой простой, там негде ошибиться.

Один из разработчиков Blender сделал коммит, который показан на первой картинке выше. Мы отследили эту ошибку с помощью PVS-Studio, и я решил написать эту очередную заметку о том, как статический анализатор помогает исправлять ляпы в коде, при условии, конечно, что его используют ;). Пишу я не про все ошибки, а только про интересные, на мой взгляд.

Некорректный код:

static void initSnapSpatial(TransInfo *t, float r_snap[3],
                            float *r_snap_precision)
{
  /* Default values. */
  r_snap[0] = r_snap[1] = 1.0f;
  r_snap[1] = 0.0f;
  *r_snap_precision = 0.1f;
  ....
}

Анализатор PVS-Studio предупреждает об аномалии, выдавая предупреждение: V519. The 'r_snap[1]' variable is assigned values twice successively. Perhaps this is a mistake. transform.c. Check lines: 1727, 1728.

Программист решил заполнить массив значениями по умолчанию, но поспешил. В результате опечатки возникает сразу две ошибки:

1. Второй элемент массива (r_snap[1]) инициализируется неправильным значением по умолчанию. Надо записать в него 1.0f, а вместо этого записывается 0.0f;
2. Третий элемент массива (r_snap[2]) вообще остаётся не инициализированным по умолчанию. Далее в этот элемент массива, быть может, будет записано другое значение, а возможно и нет. Если нет — элемент останется неинициализированным, что приведёт к неопределённому поведению.

А причём тут всё-таки Фредди? Раскрою интригу. Дело в том, что 0, 1, 2 прямо-таки притягивают ошибки. Я описывал это в статье "Ноль, один, два, Фредди заберёт тебя".

Обыгрывается песенка. Получается, что в этот раз Фредди пришёл за проектом Blender.

Как не допускать подобных ошибок?

1. Не спешить, даже при написании, казалось бы, простого кода;
2. Весь код, даже который выглядит простым/неинтересным, нужно проверять на code review.
3. Использовать PVS-Studio.

Да, не надо выбирать один пункт. Важны все три! Используйте всё сразу. Спасибо за внимание, и безбажного вам кода.

Предыдущие публикации:

1. Как PVS-Studio защищает от поспешных правок кода, пример N6.
2. Как PVS-Studio защищает от поспешных правок кода, пример N5.
3. Как PVS-Studio защищает от поспешных правок кода, пример N4.
4. Как PVS-Studio защищает от поспешных правок кода, пример N3.
5. Как PVS-Studio защищает от поспешных правок кода, пример N2.
6. Как PVS-Studio защищает от поспешных правок кода.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. 0,1,2, Freddy came for Blender.