splint vs gcc: стоят ли внешние инструменты статического анализа кода усилий для кодовых баз C?

Я работаю над довольно сложным проектом, и, как дополнительное усложнение, это встроенный в ядро ​​модуль Linux. Запуск инструмента линтинга, такого как splint, на такой кодовой базе, конечно, не невозможен [1], но тривиальных усилий было недостаточно, чтобы что-то заработало.

Прежде чем я потрачу на это больше времени, я надеялся получить некоторые отзывы и мнения по этому вопросу. При достаточном количестве флагов gcc выполняет довольно много проверок. Стоит ли использовать отдельный инструмент статического анализа кода на практике?

[1] http://www.cs.virginia.edu/pipermail/splint-discuss/2005-January/000531.html


gcc linux-kernel splint
person tramdas    schedule 22.11.2011    source источник
comment
Спасибо за ответы, Евгений и Сарнольд. Похоже, разреженное стоит делать. Coverity звучит как интересный вариант, хотя решение использовать общедоступную службу тестирования явно не может быть принято только на инженерном уровне. LDV тоже звучит интересно, посмотрю еще.   -  person tramdas    schedule 28.11.2011

Ответы (2)


arrow_upward
3
arrow_downward

Хотя splint определенно удобен, я думаю, что усилия, необходимые для его использования в исходных кодах ядра Linux, вероятно, больше, чем он принесет.

Однако у разработчиков ядра есть собственный инструмент sparse для выполнения некоторых подобных проверок, и они уже глубоко интегрировали его использование в исходные коды ядра. Интеграция его в ваши исходники тоже должна казаться довольно естественной, поскольку он уже есть во всем исходном коде ядра. Подробнее об использовании sparse см. Documentation/sparse.txt.

Существует коммерческий проект Coverity, который время от времени сканирует многие "важные" проекты с открытым исходным кодом на наличие проблем. . С помощью своего инструмента они обнаружили сотни, если не тысячи ошибок в исходных кодах ядра Linux. (Это счастливая история о том, как они рекламируют свой продукт, правительство США получает огромную кучу чрезвычайно важного проверенного кода, авторы открытого исходного кода получают бесплатные отчеты об ошибках, а пользователи открытого исходного кода получают преимущества бесплатных обзоров кода. Четырехсторонняя победа. !)

Другой вопрос, стоит ли вам приобретать экспертные знания Coverity, но интеграция с sparse даст вам некоторые преимущества инструментов статической проверки кода без лицензионных сборов.

person sarnold    schedule 22.11.2011

arrow_upward
6
arrow_downward

В дополнение к таким инструментам, как sparse, я бы посоветовал взглянуть на проект LDV. LDV ориентирован в первую очередь на проверку драйверов Linux. Эта система выполняет более глубокий статический анализ, чем splint и sparse, и может обнаруживать трудноуловимые проблемы.

LDV является бесплатным программным обеспечением.

Если вы хотите попробовать, но у вас нет времени на развертывание, у них есть служба онлайн-проверки, где вы можете загрузить свои код и проверьте его.

Кроме того, стоит обратить внимание на систему Coccinelle. Как и LDV, Coccinelle использовался для обнаружения множества различных ошибок в ядре Linux.

person Eugene    schedule 23.11.2011