---
name: checker-knowledge
description: Coverity のチェッカー（NULL_RETURNS・RESOURCE_LEAK・OVERRUN などの標準チェッカー、MISRA C:2012 と MISRA C++ の規則、CERT C / C++ の規則）ごとに、何を指摘するか、誤検知になりやすい形、確かめ方、直し方の定石、逸脱コメントの言い方、判定の目安をまとめた資料。「MISRA 10.4 の警告はどう見ればいい？」「CERT ERR33-C は逸脱でいい？」「FORWARD_NULL でよくある誤検知は？」のように、チェッカーや規則の見方を聞かれたら、答える前に必ず使う。C / C++ の Coverity の警告を調べる・直す・逸脱コメントを書くときにも、チェッカー名に合う観点を確かめるために使う。
---

# チェッカーの見方

Coverity のチェッカーごとの見方の資料です。チェッカー名で資料を選び、その項目だけを読みます。

## 資料の選び方

| チェッカー名 | 資料 |
|---|---|
| `MISRA C-2012 Rule 10.4`、`MISRA C++-2008 Rule 5-0-4` など、MISRA で始まるもの | [references/misra.md](references/misra.md) |
| `CERT` と規則の番号（`EXP34-C`、`ERR33-C`、`EXP53-CPP` など）を含むもの | [references/cert.md](references/cert.md) |
| そのほか（`NULL_RETURNS`、`RESOURCE_LEAK`、`OVERRUN` などの標準チェッカー） | [references/standard.md](references/standard.md) |

- どの資料も、先頭の目次からチェッカー・規則の項目へ飛べます。
- 項目には、指摘すること・誤検知になりやすい形・確かめ方・直し方の定石・逸脱コメントのヒント・判定の目安があります。
- MISRA・CERT の規則には、中身が標準チェッカーと同じものがあります（例：CERT EXP34-C は NULL_RETURNS・FORWARD_NULL）。資料に「同じ見方」とあれば、その項目も読みます。

## 見方を聞かれたとき（チャット）

1. チェッカー名から資料を選び、その項目を読む。
2. 項目の観点で答える。答えに、どの資料のどの項目かを添える（例「references/misra.md の Rule 10.4」）。
3. 例のコードを示されたら、その例に観点を当てはめて答える（どの被演算子の型が何か、どこを確かめるか、どう直すか）。直し方は、そのまま当てはめてよい形と、1件ずつ確かめる形を分けて示す（例：Rule 10.4 で `U` を付けると動きが変わる式がある）。
4. 1件の警告が本物かを聞かれたら、見方を示したうえで、警告の真偽を調べる手順（スキルなど）が使えれば、それで調べる。なければ、確かめ方を示し、警告経路とコードで確かめるよう伝える。
5. 逸脱コメントの例を示すときは、実際に読んだコードの場所だけを書く。コードを読んでいなければ、場所は `<関数名>()（<ファイル>:<行>）` のような印にして、置き換えるよう添える。資料の例の関数名・ファイル・行を、この警告の場所のように書かない（作った場所が Coverity に登録されてしまうため）。Coverity の注釈やイベントの名前も、警告経路で分かったものだけを書く。

ファイルを作らず、Coverity に何も書き込みません。

## 調べる・直す・逸脱コメントを書く途中で使うとき

- 項目の「確かめ方」を、警告経路をたどる手順の中で使う。「判定の目安」を判定に、「直し方の定石」を修正に、「逸脱コメントのヒント」を逸脱コメントに使う。
- 資料は手がかりで、決め手はコードです。資料とコードが食い違えば、コードを優先する。
- プロジェクトの知識（リポジトリの `.coverity-triage/knowledge.md`）が、規則の扱い（逸脱にする規則、適用しない規則）を決めていれば、そちらを優先する。

## 資料にないチェッカー

1. 資料にないことを伝える（チャット）か、結果にそう書く。
2. Coverity のチェッカーの説明を読む：頼みに書かれた説明、警告経路のファイルの `checker_description`、または Coverity からチェッカーの説明を取れる道具があれば、それで取ったもの。答えには、どの説明にもとづいたか（「示された Coverity の説明によると」など）を書く。一般の知識で補ったところは、そうと分かるように書く。
3. 説明がなく、取ることもできなければ、推測で答えない。チャットなら、チェッカーの説明か、警告の CID とストリームの名前を聞く。
4. 説明を読んだら、下の「どのチェッカーにも共通の見方」で調べる・答える。

## どのチェッカーにも共通の見方

- 警告経路は「こう動けば問題が起きる」という仮説です。★ の行で問題が起きるのに要る条件を挙げ、呼び出し元と定義までたどって確かめる。
- すべての呼び出し元が条件を満たさなければ、経路は成り立たない（誤検知）。1つでも満たせば、成り立ちうる。
- Coverity がよく見落とすもの：戻らない関数、別の関数でした検証、出力引数での初期化、マクロやビルドの設定で消えるコード、所有権の移動、ループの回数の上限。
- 判定は4つ：`true_bug`（経路が成り立ち、問題が起きる）、`false_positive`（経路が成り立たない）、`intentional`（成り立つが設計どおり）、`undetermined`（コードからは決められない）。
- ビルドの設定で消える・変わるコード（`assert` と `NDEBUG`、`#if` / `#ifdef` の構成のマクロ）は、製品のビルドの設定（どのマクロを定義してビルドするか）で答えが変わる。製品の設定がビルドの設定のファイルや知識で分からなければ `undetermined` にし、どの設定なら成り立つ・成り立たないかを書く。設定が分かれば、その設定で判定する。
- 逸脱コメントは「誤検知。」「意図的。」「本物の不具合。」で始め、問題にならない理由を条件なしで言い切り、根拠のコードの場所（`関数名()（ファイル:行）`）を書く。言い切れなければ、推奨は修正にする。