У меня он в vim и gvim интегрирован через syntastic. Анализ кода производится на лету прямо при сохранении файла. Все косяки как на ладони прямо сразу.
Дебьян-специфичные проблемы. Но так-то я бы попробовал запустить с ключом -preproc. Если будет работать, то тогда в хомяке делаем файл .splintrc и туда вписываем эту опцию. А так-то ${HOME}/.splintrc очень удобен для праильного конфигурирования splint’а. Там на каждой отдельной строке нужно указывать опции со знаком + или - (включить-выключить) и можно гибко рулить в том числе и «злобностью» splint’а.
Знать то знаю, не знаю только, насколько грамотно:
Грамотно, т.к. в 14.3.1 Preprocessing Constants самого по себе Splint Manual сказано прямо:
Splint defines the preprocessor constant S_SPLINT_S when preprocessing source files. If you want to include code that is processed only when Splint is used, surround the code with
# ifdef S_SPLINT_S
…
# endif
Значит, нормальный ход. Но то, что unistd.h в Вашем случае приходится так обходить, вот это как раз ненормально. Посмотрите – не имеет ли смысл как-то обновить splint-data или как там он у Вас называется?
Не стоит он тех денег. В нём хорошо работает только поддержка MISRA, которая нужна в очень узкоспециализированном софте. Тот же cppcheck значимо приближается к парасофту по качеству выдаваемых предупреждений, а в настройке и использовании несоизмеримо проще. Парасофт на некоторых легаси-проектах так и не удалось завести, а там, где удалось - очень много ложноположительных выстрелов, вычищать логи пришлось полуавтоматически.
Ещё есть у них Insure++, тот выдаёт более релевантные результаты и даже кое-что полезное. Но в итоге и от него отказались.
Оптимальность выбора достаточно сильно зависит от контекста.
Как мне кажется, лучшим вариантов будет совместное использование двух - Covery и PVS.
https://scan.coverity.com/ доступен бесплатно для open-source проектов и особенно удобен для больших проектов, с большой командой. Основная «фишка» в web-интерфейсе с возможностью совместной работы над разными частями проекта и т.п. Кроме этого там есть некий workflow для выявленных проблем, с различной классификацией/приоритезаций и т.д. Т.е. Coverity «помнит» найденные проблемы на стороне сервера, соответственно false-positives можно погасить один раз, не загромождая код хинтами анализатора.
PVS же славится выявлением целого класса copy-paste ошибок и в целом несколько особенным набором эвристик. Буквально я не сравнивал, но по ощущениям PVS (как минимум) очень хорошо дополняет Coverity. Однако, я (пока) не готов утверждать что PVS превосходит Coverity в «среднем по больнице».
В отношении других анализаторов, я бы сформулировал так: При использовании Coverity+PVS остальные анализаторы находят примерно только какие-то стилистические ошибки, близкие к косметике. Т.е. их использование после Coverity+PVS конечно уменьшает вероятность что-либо пропустить, но это будет скорее перфекционизмом (что тоже не плохо).
Тем не менее, будет любопытно увидеть баг, который не был замечен ни Coverity, ни PVS, но был выявлен посредством cppcheck, clang-analyzer и т.д. На всякий - давайте не путать статический анализ с runtime (Valgrind, Address Saninizer, UB-sanitizer и т.п.).
Deleted ()
Последнее исправление: Deleted
(всего
исправлений: 2)
…. мы решили предоставить возможность бесплатного использования PVS-Studio всем, кто участвует в развитии открытых проектов, размещённых на GitHub, GitLab или Bitbucket. Авторам этих проектов никаких комментариев добавлять не потребуется.
Всем желающим мы выдаём бесплатную лицензию сроком на 1 год. Чтобы получить лицензию, необходимо:
Авторам этих проектов никаких комментариев добавлять не потребуется.
Ах да, извиняюсь: эту фразу я пропустил. Вот что такое репутация — напетросянишь один раз…
Истина и по сей день отстает на полчаса от клеветы, и никто не знает, где и когда она ее настигнет. … Видно, так и будут вечно гоняться друг за другом по свету два отца Брауна: один бессовестный преступник, скрывающийся от правосудия, второй — страдалец, сломленный клеветой и окруженный ореолом реабилитации.