17

「これらのプリプロセッサマクロは常に定義されている」と明示的に言うことができる、C99コード（GCC拡張機能を含む）用の無料の静的チェッカーを探しています。

単一のターゲットプロセッサ用の埋め込みコードをコンパイルしているので、最後の部分が必要です。コンパイラ（MicrochipのC32、GCCベース）は、選択されたプロセッサに基づいてマクロを設定します。このマクロは、PIC32ヘッダーファイルで使用され、インクルードするプロセッサ固有のヘッダーファイルを選択します。したがって、 cppcheckは、多くの可能なPIC32プロセッサの1つを選択するために使用される30#ifdefの異なるを検出し、これらと他のすべての可能なすべての組み合わせを分析しようとして失敗する#defineため、失敗します。

たとえば、スプリントがC99コードを処理できる場合、私は次のように使用します。

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

追加の問題は、PIC32ツールチェーンコンパイラが呼び出されるpic32-gccだけgccでなく、これを説明する必要がある点にまだ到達していないことです。

アップデート＃1-私が興味を持っていることの1つですが、この質問に直交しているのは、Eclipseの統合です（30以上のコンパイルユニット用のmakefileを作成する必要がないのは素晴らしいことです）。私はEclipseフォーラムでこれについて質問しました（ただし、Eclipseへの統合についてはもっと議論があります）。画期的なことは何もありません。

アップデート＃2 - clangscan-buildから試してみました。

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何もしていません。それが機能しているかどうかを確認するための良いテストが何であるかはわかりません。

4

6 に答える 6

5

Clangの静的アナライザーが機能するはずです。

ソースコードのもう1つのオプションは、いくつかのプリプロセッサステートメントを使用してソースコードを#defines実行cppし、その結果のコードを静的アナライザーで実行できることです。

于 2010-04-27T03:54:29.443 に答える
3

ヘッダーの先頭に次のようなコードを追加して、定義されていることを確認できます。

#ifndef MACRO_I_NEED
#error "MACRO_I_NEED should be defined"
#define MACRO_I_NEED  // to appease cppcheck
#endif
于 2010-04-27T03:54:44.827 に答える
2

clangでscan-buildを使用する代わりに、gccを完全に交換することを検討してください。ClangのCサポートは安定しており（そしてgccをエミュレートするために最善を尽くします）、コードを適切に処理する必要があります。

のようなものを試してmake -j3 CC=clang、何が起こるか見てください！

PS。その構文は完全に間違っている可能性があります。何年もの間makefileを使用していません（CMakeは素晴らしいです）。

于 2010-06-27T03:17:01.700 に答える
2

コードで実行する実際の分析に応じて、Frama-Cを確認できます。指示されたCプリプロセッサを使用するため、必要に応じてPIC32のCPPを使用できます。

于 2010-06-27T23:39:26.930 に答える
1

sunifdefのようなツールを使用して、想定される定義済みマクロに従ってソースコードを部分的に前処理することができます。これらの定義の影響を受けるシステムヘッダーとライブラリヘッダーのコピーを作成し、それらも処理する必要があります。次に、静的分析を行うときに、すでに処理されたヘッダーを指す別のインクルードパスを指定します。

于 2010-06-25T17:06:45.787 に答える
1

これは直接解決策を提供しないかもしれませんが、独自の静的構文アナライザーであるCoverityを検討することを検討するかもしれませんが、OSプロジェクトでは無料です。それはあなたのニーズに関する仕事をするはずです！

乾杯！

于 2010-04-28T19:43:18.920 に答える