Бесплатная статическая проверка для кода C99

17

Я ищу бесплатную статическую проверку кода C99 (включая расширения GCC) с возможностью явно сказать «эти макросы препроцессора всегда определены».

Мне нужна эта последняя часть, потому что я компилирую встроенный код для одного целевого процессора. Компилятор (Microchip C32, основанный на GCC) устанавливает макрос на основе выбранного процессора, который затем используется в заголовочных файлах PIC32, чтобы выбрать специфичный для процессора заголовочный файл для включения. cppcheck не работает, потому что он обнаруживает 30 различных #ifdef s, использованных для выбора одного из множества возможных процессоров PIC32, пытается проанализировать все возможные их комбинации, а также все другие #define s, и не выполнить.

Например, если splint может обработать код C99, я бы использовал

splint -D__PIC32_FEATURE_SET__=460 -D__32MX460F512L__ \
-D__LANGUAGE_C__ -I/path/to/my/includes source.c

Дополнительная проблема состоит в том, что компилятор цепочки инструментов PIC32 называется pic32-gcc , а не просто gcc , хотя я еще не дошел до необходимости учитывать это.

Обновление № 1 . Одна вещь, которая меня интересует, но ортогональна этому вопросу, - это интеграция с Eclipse (было бы неплохо не писать make-файл для более 30 модулей компиляции ). Я спрашивал об этом на форумах Eclipse (хотя обсуждение там больше о интеграция в Eclipse). Ничего революционного.

Обновление № 2 - только что попробовал scan-build из clang , используя:

scan-build --use-cc=/usr/local/bin/pic32-gcc make -B -k all

... (также без флага --use-cc ), но все, что я получил, было типичным результатом сборки, примером которого является:

Building file: ../src/MoreMath.c
Invoking: PIC C32 C Compiler
pic32-gcc -D__DEBUG -I/usr/local/pic32-libs/include -O0 -Wall -c -fmessage-length=0 -std=gnu99 -Werror-implicit-function-declaration -MMD -MP -MF"src/MoreMath.d" -MT"src/MoreMath.d" -mprocessor=32MX460F512L -D__DEBUG -g -o"src/MoreMath.o" "../src/MoreMath.c"
Finished building: ../src/MoreMath.c

... и в конце:

Building target: MyBinary.elf
Invoking: PIC C32 C Linker
pic32-gcc -Wl,-Map,MyBinary.map -mprocessor=32MX460F512L --defsym=__MPLAB_DEBUG=1 -o"MyBinary.elf" <<ALL OF MY *.o FILES HERE>>
Finished building target: MyBinary.elf

scan-build: Removing directory '/tmp/scan-build-2010-06-21-1' because it contains no reports.

Так что либо мой код идеален в соответствии с scan-build , либо он ничего не делает. Я не уверен, что хороший тест, чтобы увидеть, работает ли он.

    
задан detly 27.04.2010 в 05:51
источник
  • Вы должны добавить свое условие, которое будет использоваться в Eclipse, на ваш вопрос, если это действительно является требованием для вашего решения. –  Matt B. 21.06.2010 в 03:37
  • Нет, это будет дополнительный бонус. Я отредактирую вопрос, чтобы сделать это более ясным. Я по-прежнему wokring о получении сканирования-сборки для работы с PIC32 toolchain, и если да, я буду принимать ответ ниже. –  detly 21.06.2010 в 03:52
  • @Adam Davis - я собирался подправить вопрос, чтобы лучше подчеркнуть мое использование инструментальной цепочки PIC32, но я не знаю, повлияет ли это на вашу мотивацию пожертвовать щедростью. Дайте мне знать, если вы хотите, чтобы я подождал. –  detly 21.06.2010 в 06:58
  • Привет, я не хочу задавать вопрос, не относящийся к теме, но мне очень любопытно. Почему кто-то хочет запрограммировать микрочип? Что вы строите? Благодаря.. –  the_machinist_ 28.06.2010 в 01:46
  • Микрочип является частью системы управления для некоторых электронных устройств. Они почти полностью автоматические, поэтому он контролирует условия через бортовые датчики (и какие есть несколько входов), и настраивает различные периферийные устройства для поддержания определенных рабочих состояний. –  detly 28.06.2010 в 02:16

6 ответов

5

Статический анализатор Clang должен работать.

Другой вариант с исходным кодом #defines заключается в том, что вы можете запустить cpp над исходным кодом с некоторыми операторами препроцессора, а затем запустить этот результирующий код через статический анализатор.     

ответ дан Bill Lynch 27.04.2010 в 05:54
  • Я думаю, что scan-build примерно так же хороша, как я могу получить. Я развиваюсь под Eclipse и использую внутренний конструктор (т. Е. Явный make-файл), и я не думаю, что для Eclipse CDT существует интеграция clang. Возможно, стоит переключиться на проект на основе make-файла. –  detly 27.04.2010 в 07:00
  • Увы, я не вижу способа заставить scan-build (или любые инструменты Clang) работать с Eclipse. –  detly 10.06.2010 в 04:44
  • @detly: Почему на Земле есть опытный программист на C, такой как вы, связанный с нечестивой мерзостью, такой как Eclipse? –  Matt Joiner 19.11.2010 в 17:29
  • @Matt Joiner - что бы вы порекомендовали? (Кроме того, я думаю, что в этом случае это был не Eclipse, а просто, что scan-build не работала так, как я ожидал.) –  detly 21.11.2010 в 03:28
  • stackoverflow.com/questions/3528079/... –  Matt Joiner 21.11.2010 в 05:04
Показать остальные комментарии
3

Вы можете просто добавить такой код в верхнюю часть заголовка, который гарантирует его определение:

#ifndef MACRO_I_NEED
#error "MACRO_I_NEED should be defined"
#define MACRO_I_NEED  // to appease cppcheck
#endif
    
ответ дан Adam Rosenfield 27.04.2010 в 05:54
  • Не нужно ли мне делать это для каждого исходного файла? –  detly 27.04.2010 в 06:11
  • @detly: необязательно - если у вас есть файл заголовка, который включает в себя каждый файл (например, предварительно скомпилированный заголовок), вы можете поместить его вверху. –  Adam Rosenfield 27.04.2010 в 20:18
2

Вместо использования scan-build с clang, рассмотрите возможность замены gcc в целом! Поддержка Clang's C стабильна (и делает все возможное, чтобы эмулировать gcc), и должна нормально обрабатывать ваш код.

Попробуйте что-то наподобий make -j3 CC=clang и посмотрите, что получится!

PS. Этот синтаксис может быть совершенно неверным. Давным-давно не использовал make-файлы (кстати, CMake потрясающий).

    
ответ дан Clark Gaebel 27.06.2010 в 05:17
  • cmake ужасно! –  Matt Joiner 27.06.2010 в 11:13
  • Он не поддерживает параметр -MT, а это значит, что я должен переписать много make-файлов. В настоящее время в сборке используются файлы автозависимости - .d-файлы, которые содержат зависимости заголовков для каждого .o-файла. Пройдет какое-то время, прежде чем я смогу проверить это. –  detly 28.06.2010 в 04:56
  • @detly, сгенерировать файлы зависимостей и вырезать их обработку (в основном, шаблоны, я полагаю) в вашем Makefile)? –  vonbrand 02.02.2013 в 20:45
2

В зависимости от того, какой именно анализ вы хотите выполнить в своем коде, вы можете взглянуть на Frama-C . Он использует любой препроцессор C, о котором вы говорите, так что вы можете использовать CPP PIC32, если хотите.

    
ответ дан porges 28.06.2010 в 01:39
1

Это может не дать вам прямого решения, но вы можете рассмотреть возможность использования Coverity, который является проприетарным анализатором статического синтаксиса, но это бесплатно для проектов ОС. Это должно сделать работу, касающуюся ваших потребностей!

Ура!

    
ответ дан damien.courousse 28.04.2010 в 21:43
  • Это не проект OSS. –  detly 28.06.2010 в 04:50
1

Вы можете использовать такой инструмент, как sunifdef , чтобы частично предварительно обработать исходный код в соответствии с предполагаемыми определенными макросами. Вы должны будете делать копии системных и библиотечных заголовков, на которые влияют эти определения, а также обрабатывать их. Затем при выполнении статического анализа вы должны указать другой путь включения, указывающий на уже обработанные заголовки.

    
ответ дан Geoff Reedy 25.06.2010 в 19:06
  • Coan (coan2.sourceforge.net), по-видимому, является последним fork / расширением набора инструментов unifdef –  Morten Jensen 26.08.2013 в 14:01