Когда разработчики делают ошибки, это часто происходит случайно или потому, что разработчики спешат. Эти ошибки часто проявляются в небольших правках кода. Рассмотрим один из таких случаев: разработчик исправляет ошибку и одновременно добавляет новую.
Собственно, изображение выше уже все демонстрирует. Вам даже не нужно читать дальше :). Тем не менее, я все же хотел бы поговорить о том, что мы здесь видим, что я и собираюсь сделать.
Еще в 2021 году я начал мониторить Blender — проект с открытым исходным кодом — на наличие ошибок. Я использовал анализатор PVS-Studio, чтобы просканировать его и найти ошибки. Поскольку Blender развивается быстрыми темпами, я довольно часто получал предупреждения PVS-Studio о новом коде. К сожалению, я не мог своевременно на них отреагировать, так как был занят всем остальным. Много встреч, одна статья за другой — и еще что-то между ними. Так что я в основном пропустил большую часть этих предупреждений :( . В итоге за тот год я выложил всего пару заметок о свежих ошибках — хотя мог бы написать и больше.
Вчера заметил новое сообщение с двумя предупреждениями. Вот я и подумал, а почему бы и не посмотреть? Тем более, что у меня была пара минут. Одно предупреждение было не таким уж интересным, а вот второе было настоящей находкой. Это определенно был знак, чтобы я сосредоточился и написал, как PVS-Studio может обнаруживать ошибки при регулярном использовании :).
Итак, @Antonioya внесла две новые строки, предназначенные для исправления следующей ошибки: Исправить T94903: GPencil: копирование ключей не сохраняет тип ключевого кадра.
Разработчик торопился и так и не заметил, что указатель, с которым он работал, может быть нулевым. Код проекта содержит проверку nullptr, подтверждающую это:
gpf->key_type = gpfs->key_type;
if (gpf) {В свою очередь, анализатор PVS-Studio обнаружил аномалию и выдал предупреждение: V595 [CWE-476]: Указатель ‘gpf’ был использован до его проверки на nullptr. Проверьте строки: 458, 459. editaction_gpencil.c
И это верный способ заметить множество ошибок и сэкономить время, которое можно было бы потратить на их исправление. Этому же разработчику гораздо проще вернуться к коду, который они написали, и исправить его, чем компании исправить эту ошибку, когда она дойдет до QA или пользователей.
P.S. Сначала я хотел просто назвать статью Как PVS-Studio предотвращает необдуманные изменения кода, но потом обнаружил, что у нас уже есть статья с таким названием. Поэтому я добавил пример N2. Надеюсь, что со временем мы будем писать все больше и больше таких статей. Спасибо за ваше время — и попробуйте включить PVS-Studio в свой процесс разработки!
