Открыть список
Как стать автором
Обновить

Комментарии 18

В дополнение к словам коллеги о режиме независимой проверки препроцессированных файлов, хочу отдельно подчеркнуть, что смысл использования такого режима состоит прежде всего в его простоте. По нашему опыту, в большинстве сборочных систем проще добавить к параметрам компиляции всех файлов ещё один флажок, чем встраивать вызов анализатора «параллельно» с компилятором. И хотя прямая интеграция анализатора в сборочный процесс безусловно является «идеологически» более верным решением, такой вариант не всегда удобен, чтобы быстро «попробовать» анализ на своём проекте.
Пардон за ламерский вопрос, а разве разные препроцессры работают по-разному?
Я думал, уж что-что, а простая макроподстановка должна работать одинаково…
Да, по-разному (к нашему сожалению), и оказывается даже довольно сильно. У нас есть внутренний список отличий/проблем в разных препроцессорах — это сильно усложняет нашу жизнь.
Ого. А в чем могут быть различия?
Например, в некоторых разворачивается и исполняется завёрнутая в макрос #pragmа, что не соответствует стандартам, но сильно облегчает жизнь. Т.е.
#define ALIGN4 #pragma pack(4)
ALIGN4
не должно работать, но работает. Кажется даже в GCC есть на этот случай исключение. И тому подобные вещи. Сравнения всякие находил по-разному работающие. А уж математика…
Понял, спасибо.
Хм, по стандарту это бы превратилось в "pragma" pack(4) или что-то подобное?
Не пробовали проверить своим анализатором linux kernel, или различия C и С++ не дают этого сделать?
У нас анализатор и C, и С++ поддерживает.

Пробовали. Статью пока не написали, так как там ОЧЕНЬ сложный код, который ОЧЕНЬ сложно читать и понимать, есть ли там ошибка или нет.
Поддержку Apple OS X и плагин для интеграции в Xcode не думаете реализовать?
На самом деле, плагин для Xcode — это вообще не обязательно, да и помоему официальных путей сейчас нет. Но можно проще — у Xcode есть папка DerivedData — куда собственно и падают, все промежуточные файлы сборки проекта. Там много чего, но в том числе есть и d/dia/o файлы. Сейчас пропробую проверить чтобы он туда и i файлы добавлял. Т.е. по хорошему пути к этой папке вам достаточно, чтобы запустить свой анализатор.

Другое дело, то что clang там например такой сейчас
Apple LLVM version 5.0 (clang-500.2.75) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

И он может таки отличатся, от стандартного.
Что мешает пользоваться уже существующим решением с проверкой .i-файлов?
Очень полезный инструмент, мы с его помощью много редких ошибок нашли. Спасибо за ключик.

p.s. О, FlylinkDC на 6 скриншоте.
На мой взгляд, главный плюс отдельной утилиты, а также главный сценарий это встраивание в среду непрерывной интеграции (Jenkins/TeamCity). Но ограничивающим моментом я вижу отдельный формат результатов с собственным просмотрщиком.
Должен быть XML/HTML или даже txt, но главное формат который можно просмотреть в браузере.
У нас УЖЕ и xml, и txt, и встраивание в среду непрерывной интеграции…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.