Наше руководство недавно беседовало с некоторыми людьми, продающими C++ static analysis tools. Конечно, продавцы говорят, что найдут множество ошибок, но я настроен скептически.Насколько эффективны инструменты для анализа статического кода на C++?
Как эти инструменты работают в реальном мире? Находят ли они настоящие ошибки? Помогают ли они более младшим программистам учиться?
Стоит ли проблем?
Уплата большинства инструментов статического анализа, вероятно, не нужна, когда есть некоторые очень качественные бесплатные (если вам не нужна какая-то особая или специфическая функция, предоставляемая коммерческой версией). Например, см. Этот ответ, который я дал по другому вопросу о cppcheck.
Я использовал их - например, PC-Lint, и они нашли что-то. Как правило, они настраиваются, и вы можете сказать им, что «перестаньте беспокоить меня о xyz», если вы определите, что xyz действительно не проблема.
Я не знаю, что они помогают младшим программистам многому научиться, но их можно использовать в качестве механизма, чтобы помочь подтянуть код.
Я обнаружил, что второй набор (скептический, зондирующий для ошибок) глаз и модульное тестирование, как правило, там, где я видел больше ловушек ошибок.
Когда я использовал PC-Lint в проекте C++, я включил Effective C++/More Effective C++ предупреждения и перечитал раздел книги, когда я нарушил одно из правил. Это действительно помогло мне понять эти правила в реальном мире. Я нашел это очень полезным. – Trent
Это действительно помогает. Я бы предложил взять пробную версию и запустить ее через часть вашей кодовой базы, которая, по вашему мнению, игнорируется. Эти инструменты генерируют много ложных срабатываний. Как только вы пробрались через них, вы, вероятно, найдете переполнение буфера или два, которые могут сэкономить много горя в ближайшем будущем. Кроме того, попробуйте по крайней мере две/три разновидности (а также некоторые из материалов OpenSource).
+1 для предложения с использованием пробной версии. Я собирался сделать это сам. –
Эти инструменты действительно помогают. lint - отличный инструмент для разработчиков C.
Но одно возражение, которое у меня есть, это то, что они пакетные процессы, которые запускаются после того, как вы написали достаточное количество кода и потенциально генерируете много сообщений.
Я думаю, что лучший подход заключается в том, чтобы создать такую вещь в вашей среде IDE и указать на проблему, пока вы ее пишете, чтобы сразу ее исправить. Не позволяйте этим проблемам попасть в базу кода в первую очередь.
В этом разница между инструментом статического анализа FindBugs для Java и Инспектором IntelliJ. Я очень предпочитаю последнее.
Существует плагин Eclipse для FindBugs. –
У вас есть пример интерактивного инструмента статического анализа для C++? Я никогда не видел его, но мне было бы интересно его увидеть. – Tom
Я разработчик на redlizards.com - мы создаем Goanna, статический аналитический инструмент C/C++, который имеет разные версии для работы с ночной сборкой, а также интегрируется в IDE (плагины VS и eclipse). Возможно, стоит посмотреть. –
Я думаю, это зависит от вашего стиля программирования. Если вы в основном пишете C-код (со случайной функцией C++), то эти инструменты, вероятно, смогут помочь (например, управление памятью, переполнение буфера, ...). Но если вы используете более сложные функции C++, тогда инструменты могут запутаться при попытке проанализировать исходный код (или просто не найдете много проблем, потому что средства на C++ обычно безопаснее использовать).
Это соответствует моему опыту. Когда я использовал PC-Lint 3 или 4 года назад, это было слишком шумно, и даже после набора его назад он жаловался на слишком много вещей, которые не были проблемой. –
Это было в базе кода, которая использовала довольно продвинутые возможности C++. –
Анализ статического кода почти всегда стоит того. Проблема с существующей базой кода заключается в том, что она, вероятно, сообщит слишком много ошибок, чтобы сделать ее полезной из коробки.
Я когда-то работал над проектом, в котором было 100 000+ предупреждений от компилятора ... нет смысла запускать инструменты Lint на этой базе кода.
Использование инструментов «Линт» «право» означает покупку лучшего способа (что хорошо). Одна из лучших работ, которые у меня были, работала в исследовательской лаборатории, где нам не разрешалось проверять код с предупреждениями.
Итак, да, инструменты стоят того ... в долгосрочной перспективе. В краткосрочной перспективе включите предупреждения своего компилятора до максимума и посмотрите, что он сообщает. Если код «чистый», тогда время, чтобы посмотреть инструменты линта, теперь. Если код содержит много предупреждений ... расставьте приоритеты и исправьте их. Как только код не имеет предупреждений (или, по крайней мере, очень мало), посмотрите на инструменты Lint.
0 Рекомендуем почитать также топико:
Edit:
В случае предупреждения о товаре 100,000, он был разбит около 60 проектов Visual Studio. Поскольку каждый проект удалял все предупреждения, он был изменен, чтобы предупреждения были ошибками, что предотвращало добавление новых предупреждений в проекты, которые были очищены (точнее, это позволяло моему коллеге праведно кричать на любого разработчика, который проверял в код без его компиляции сначала :-)
Недавно я работал над новым аппаратным/программным продуктом в моей компании, мне посчастливилось убедить ответственного парня изменить некоторые предупреждения компилятора на ошибки.Изменение предупреждений-ошибок заставило всех избавиться от этих предупреждений. –
Это изменение флагов компилятора было лучшим, что я получил, чтобы изменить наш «стиль кодирования» и «процессы», не имея при этом необходимости отправлять мандат электронной почты всем. –
Я думаю, что один из моих самых счастливых дней был проверкой изменений на 60 проектов с/W4 на них :-) – TofuBeer
Статический анализ, который находит реальные ошибки, стоит того, независимо от того, является ли он C++ или нет. Некоторые из них, как правило, довольно шумные, но если они могут поймать тонкие ошибки, такие как сопоставленные/неподписанные сравнения, вызывающие оптимизации, которые нарушают ваш доступ к массиву или из пределов доступа, они, безусловно, стоят усилий.
Возможно, вам придется иметь дело с хорошим количеством ложных срабатываний, особенно если ваша база кода большая.
Большинство инструментов статического анализа работают с использованием «внутрипроцедурного анализа», что означает, что они рассматривают каждую процедуру изолированно, в отличие от «анализа всей программы», которая рассматривает всю программу.
Обычно они используют «внутрипроцедурный» анализ, потому что «анализ всей программы» должен учитывать многие пути через программу, которая на самом деле никогда не произойдет на практике и, следовательно, может часто генерировать ложноположительные результаты.
Внутрипроцессный анализ устраняет эти проблемы, просто сосредоточив внимание на одной процедуре. Однако для работы обычно требуется ввести «язык аннотации», который вы используете для описания метаданных для аргументов процедуры, типов возвращаемых данных и полей объектов. Для C++ эти вещи обычно реализуются с помощью макросов, которые вы украшаете. Затем аннотации описывают такие вещи, как «это поле никогда не является нулевым», «этот строковый буфер защищен этим целочисленным значением», «к этому полю может быть обращено только поток с надписью« фон »» и т. Д.
Анализ инструмент затем возьмет предоставленные вами аннотации и проверит, что написанный вами код действительно соответствует аннотациям. Например, если вы могли бы передать значение null в значение, помеченное как не равное null, оно будет отмечать ошибку.
В отсутствие аннотаций инструмент должен принять худшее, и поэтому будет сообщаться много ошибок, которые на самом деле не являются ошибками.
Поскольку, похоже, вы уже не используете такой инструмент, вы должны предположить, что вам придется потратить значительное количество времени на аннотирование кода, чтобы избавиться от всех ложных срабатываний, которые изначально будут сообщены. Сначала я запускаю инструмент и подсчитываю количество ошибок. Это должно дать вам оценку того, сколько времени вам потребуется, чтобы принять его в базе кода.
Wether or not the tool стоит того, что зависит от вашей организации. Каковы типы ошибок, которые вам больше всего нравятся? Будут ли они перегружать ошибки? Являются ли они ошибками, вызванными нулевыми ошибками или ошибками памяти? Являются ли они проблематичными? Являются ли они «упущенными, что мы не рассматривали этот сценарий», или «мы не тестировали китайскую версию нашего продукта на литовской версии Windows 98?».
Как только вы выясните, в чем состоят проблемы, вы должны знать, стоит ли это усилий.
Инструмент, вероятно, поможет с ошибками переполнения буфера, нулевой разыгрывания и ошибок утечки памяти. Есть вероятность, что он может помочь с ошибками в потоковой передаче, если он поддерживает анализ «раскраски нитей», «эффектов» или «разрешений». Тем не менее, эти типы анализа довольно передовые и имеют ОГРОМНОЕ нотационное бремя, поэтому они действительно приносят с собой некоторые расходы. Инструмент, вероятно, не поможет с другими типами ошибок.
Таким образом, это действительно зависит от того, какое программное обеспечение вы пишете, и какие ошибки вы используете чаще всего.
Приятной особенностью C++, однако, является то, что встроенные функции и шаблоны означают, что много информации имеется в одном ТУ. Поэтому хороший инструмент статического анализа может выполнять межпроцедурный анализ функций, которые видны в ТУ. –
Мое главное состоит в том, что эти инструменты имеют потенциально высокие затраты на усыновление и только улавливают ошибки ограниченного класса. Это означает, что они не являются «универсальными» решениями. Они могут иметь решающее значение для некоторых проектов и пустая трата времени для других. Использование их должно основываться на индивидуальной потребности. –
Я думаю, что статический анализ кода стоит того, если вы используете правильный инструмент. Недавно мы попробовали инструмент Coverity Tool (немного дорогой). Его удивительный, он выявил много критических дефектов, которые не были обнаружены ворсом или очищены.
Также мы обнаружили, что мы могли бы избежать 35% дефектов поля клиента, если раньше мы использовали покрытие.
Теперь обложка выставляется в моей компании, и когда мы когда-либо получаем клиентскую версию TR в старой версии программного обеспечения, мы используем покрытие, чтобы выявить возможные недостатки для вины, прежде чем мы начнем анализ в susbsytem.
По моему опыту с несколькими работодателями, Coverity Prevent for C/C++ явно стоило того, чтобы найти некоторые ошибки даже в хорошем коде разработчиков и множество ошибок в коде худших разработчиков. Другие уже затронули технические аспекты, поэтому я сосредоточусь на политических трудностях.
Во-первых, разработчики, чей код нуждается в статическом анализе больше всего, наименее вероятно используют его добровольно. Поэтому, боюсь, вам понадобится сильная управленческая поддержка, как на практике, так и в теории; в противном случае он может оказаться как элемент контрольного списка, чтобы получить впечатляющие показатели без фактического исправления ошибок. Любой инструмент статического анализа будет создавать ложные срабатывания; вам, вероятно, понадобится посвятить кого-то, чтобы свести к минимуму раздражение от них, например, путем устранения дефектов, определения приоритетов шашек и настройки настроек. (Коммерческий инструмент должен быть очень хорош в том, что он никогда не демонстрирует ложных срабатываний более одного раза, это само по себе может стоить того.) Даже настоящие дефекты, вероятно, вызовут раздражение; мой совет в этом не беспокоиться, например, замечания по регистрации, ворчащие, что, очевидно, разрушительные ошибки являются «второстепенными».
Мой самый большой совет - следствие моего первого закона, выше: сначала возьмите дешевые снимки , и посмотрите на мучительно очевидные ошибки от ваших худших разработчиков. Некоторые из них, возможно, даже были обнаружены предупреждениями компилятора, но многие ошибки могут проскальзывать через эти трещины, например, когда они подавляются параметрами командной строки. На самом деле вопиющие ошибки могут быть политически полезными, например, с десяткой списков самых смешных дефектов, которые прекрасно могут сосредоточить ум, если их использовать осторожно.
Скрытность выполняется только с помощью анализа файлов, поэтому, если вы хотите проанализировать, как функции взаимодействуют между файлами источников, вам необходимо нанять нескольких людей * (поскольку эти инструменты не могут выполнять весь анализ программы) *. – user2284570
Как и все, от ответа зависит ... если вы единственный разработчик, работающий над принцессой вязального шаблона для вас, бабушка, вы, вероятно, не захотите покупать какие-либо инструменты для статического анализа. Если у вас есть проект среднего размера для программного обеспечения, который войдет во что-то важное и, возможно, помимо того, что у вас ограниченный график, вы можете немного инвестировать сейчас, что значительно сэкономит вам больше времени.
Недавно я написал общую тираду об этом: http://www.redlizards.com/blog/?p=29
я должен написать часть 2, как только позволит время, но в целом сделать некоторые грубые расчеты, стоит ли это для вас:
Мой личный принимают также:
получить статический анализ в начале
предоставляют разработчику возможность использовать статический анализ сам
Как заметили пара людей, если вы запускаете инструмент статического анализа в большинстве приложений, вы получите много предупреждений, некоторые из них могут быть ложными срабатываниями или могут не привести к эксплуататорскому дефекту. Именно этот опыт приводит к восприятию того, что эти типы инструментов являются шумными и, возможно, пустая трата времени. Тем не менее, есть предупреждения, которые будут выявлять реальные и потенциально опасные дефекты, которые могут привести к проблемам безопасности, надежности или правильности, и для многих команд эти проблемы важны для исправления и могут быть почти невозможны для обнаружения через тестирование.
Таким образом, инструменты статического анализа могут быть очень полезными, но применение их к существующей кодовой базе требует небольшой стратегии. Вот несколько советов, которые могут вам помочь.
1) Не включайте все сразу, выбирайте начальный набор дефектов, включайте эти анализы и фиксируйте их по базе кода.
2) Когда вы обращаетесь к классу дефектов, помогите всей команде разработчиков понять, что такое дефект, почему это важно и как кодировать для защиты от этого дефекта.
3) Работать, чтобы полностью очистить кодовую базу от этого класса дефектов.
4) Как только этот класс проблем был исправлен, введите механизм, чтобы оставаться в состоянии нулевой проблемы. К счастью, гораздо проще убедиться, что вы не повторно вводите ошибку, если у вас есть базовый уровень, нет ошибок.
У бывшего работодателя у нас был Insure ++. Это помогло точно определить случайное поведение (использование неинициализированного материала), которое Valgrind не смог найти. Но самое главное: он помогает удалить ошибки, которые еще не были известны как ошибки.
Insure ++ - это хорошо, но дорого, поэтому мы купили только одну пользовательскую лицензию.
Этот довольно удивительный результат был выполнен с использованием Эльзы и Оинка.
http://www.cs.berkeley.edu/~daw/papers/fmtstr-plas07.pdf
"Крупномасштабная Анализ Уязвимость форматной строки в Debian Linux" Карла Чен, Дэвид Вагнер, UC Беркли, {огнеупорной, daw}@cs.berkeley.edu
Аннотация:
Ошибки в формате строки являются относительно общей уязвимостью системы безопасности и могут привести к произвольному выполнению кода. В сотрудничестве с другими нами мы разработали и внедрили систему для устранения уязвимостей строки формата из всего дистрибутива Linux, используя вывод типаquali fier, метод статического анализа, который может обнаруживать нарушения в нарушении. Мы успешно анализируем 66% исходных пакетов C/C++ в дистрибутиве Debian 3.1 Linux. Наша система содержит предупреждения об ограничении строки в 1533 формате. По нашим оценкам, 85% из них являются истинными позитивами, то есть реальными ошибками; игнорируя дубликаты библиотек, около 75% являются настоящими ошибками. Мы предлагаем, чтобы существовала технология для устранения уязвимостей форматированной строки в ближайшем будущем.
Категории и тематические дескрипторы D.4.6 [Операционные системы]: Безопасность и защита-инвазивное программное обеспечение; Общие условия: безопасность, языки; Ключевые слова: уязвимость форматирования строк, крупномасштабный анализ, вывод о том, что Typequali fier
John Carmack недавно написал об этом: http://altdevblogaday.com/2011/12/24/static-code-analysis/ –
John Carmack. Анализ статического кода. Новая ссылка: http://www.viva64.com/ru/a/0087/ – 2015-03-25 06:59:52
@DavidNorman: Они все делают только файл по анализу файлов, поэтому, если вы хотите проанализировать, как функции взаимодействуют между файлами источников, вам необходимо нанять сталь несколько народов * (поскольку эти инструменты не могут выполнять весь анализ программы) *. – user2284570