ROS Newsletter79

Выпуск новостей ReactOS №79

• Публикация в архиве

Статический анализ в Coverity

Недавно команда ReactOS вновь воспользовалась программным обеспечением компании Coverity для статического анализа исходного кода проекта. Хотя благодаря усовершенствованиям в алгоритме сканера Coverity в коде ReactOS и было найдено несколько новых ошибок, однако подавляющее большинство обнаруженных проблем разделилось на две категории: ложные срабатывания из-за способа реализации и использования портируемой библиотеки структурированной поддержки исключений (PSEH), а также сообщения о некорректности стороннего кода, не разрабатываемого в рамках данного проекта. Мы надеемся, что настройка анализатора на игнорирование факта использования PSEH снизит количество ложных срабатываний при последующих сканированиях, однако проблемы, обнаруженные в стороннем коде - это совершенно другой вопрос. Некоторые сторонние разработчики, код которых мы используем в ReactOS, также направляют свой код в Coverity для анализа, поэтому вся ответственность по исправлению обнаруженных ошибок лежит в первую очередь на них, хотя разработчики ReactOS готовы предоставить отчёты об ошибках или патчи, если мы не увидим с их стороны каких-либо действий по устранению этих ошибок. При этом остальные проекты не используют систему анализа исходного кода, и команда ReactOS постарается предоставить им полученные в результате сканирования данные, чтобы помочь им в разработке.

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

Буферы FASTFAT

Сканирование в Coverity выявило, что старый драйвер FAT является "проблемным местом", поскольку в нём были обнаружены ошибки, связанные с переполнением буфера и приводящие к выходу за пределы выделенной для этого буфера области памяти. Пьер Швейцер (Pierre Schweitzer) исследовал код и обнаружил, что по какой-то причине в драйвере FAT имеется три разных буфера, используемых для одной цели и при некоторых операциях было невозможно определить, какой из буферов используется в данный момент. Синхронизировались ли они вообще? На этот вопрос так и не нашлось ответа, поэтому результат операций, использующих эти буферы, довольно сложно определить.

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

Новый разработчик

Роэль Мессан (Roel Messiant) недавно присоединился к проекту и исправил несколько ошибок, обнаруженных Coverity. На IRC-канале Роэль известен под именем Mephisto, и, несмотря на ник, оказался значительно более полезным, чем его тёзка по нику (Мефистофель), а мы с нетерпением ждём, что ещё нового он принесёт в проект.