---
generated_at: 2026-02-22 10:00:00
metrics:
  claims_total: 40
  claims_with_evidence: 38
  claims_without_evidence: 2
confidence_derived: 0.95
---

# 根拠レポート：src-random 単体テストケース一覧

## 本レポートについて

### 目的
本レポートは、生成された単体テストケース一覧（src-random.csv）の信頼性を検証し、人間レビュアーが効率的にレビューできるようにすることを目的としています。

### チェック方法
以下の観点でドキュメントの内容（Claim：主張）を検証しています：

1. **根拠の有無確認**：各主張に対して、ソースコード・既存設計書・要件定義書などの根拠（Evidence）が存在するか
2. **根拠との整合性**：主張の内容が根拠と矛盾していないか
3. **網羅性**：参照すべき情報源を適切にカバーしているか

### 信頼度スコアの算出
- **confidence_derived** = 根拠あり件数 / 総主張件数
- 状態「○」：根拠あり、「△」：根拠不足または要確認

### 本レポートの使い方
1. まず「サマリー」で全体の信頼度と優先レビュー項目を確認
2. 「Claims と根拠の対応」で △ の項目を重点的にレビュー
3. 「不足情報」で補完が必要な情報源を確認

---

## 1) サマリー（まず見るところ）
- 総合信頼度（derived）：**0.95**
  - 根拠あり：38 / 40、根拠なし：2
- 優先レビュー（高）
  1. **C-39（連続呼び出しで異なる乱数）**：乱数の一意性は確率的な主張であり、コードから保証できない
  2. **C-40（乱数データの実生成確認）**：バッファ内容の変更はプラットフォーム依存であり、コードの構造からは間接的にしか確認できない

## 2) 参照した情報（Evidence一覧）
> ここに「実在するもの」だけ列挙。抽出フェーズで付けたIDをそのまま出す。

- E-01: `src/random.c` 100行目 - buflen > 0x7FFFFFFFu のチェック
- E-02: `src/random.c` 103行目 - flags != 0 のチェック
- E-03: `src/random.c` 106-107行目 - cb == NULL の場合の同期処理分岐
- E-04: `src/random.c` 109-122行目 - 非同期モードのリクエスト初期化とワーク投入
- E-05: `src/random.c` 31-70行目 - uv__random関数のプラットフォーム別分岐
- E-06: `src/random.c` 38-42行目 - Apple/OpenBSD向けgetentropy -> devurandomフォールバック
- E-07: `src/random.c` 45-48行目 - Linux/FreeBSD向けgetrandom -> devurandomフォールバック
- E-08: `src/random.c` 49-61行目 - Linux向けdevurandom失敗時のsysctlフォールバック（switch文）
- E-09: `src/random.c` 73-78行目 - uv__random_work関数の実装
- E-10: `src/random.c` 81-91行目 - uv__random_done関数の実装
- E-11: `src/random.c` 87-88行目 - status == 0 の場合にreq->statusを使用する条件分岐
- E-12: `src/random.c` 85行目 - uv__req_unregisterの呼び出し
- E-13: `src/random.c` 90行目 - コールバック呼び出し（req->cb）
- E-14: `src/random.c` 116-120行目 - uv__work_submitにUV__WORK_CPUを指定
- E-15: `include/uv.h` 1791-1808行目 - uv_random_s構造体定義とuv_random関数宣言
- E-16: `include/uv.h` 1807行目 - flags引数のコメント「For future extension; must be 0.」
- E-17: `src/random.c` 50-60行目 - switch文のcaseラベル一覧（UV_EACCES, UV_EIO, UV_ELOOP, UV_EMFILE, UV_ENFILE, UV_ENOENT, UV_EPERM）

## 3) Claims と根拠の対応（レビューの主戦場）
| Claim ID | 主張 | Evidence | 状態 |
|---|---|---|---|
| C-01 | コールバックNULLで同期的に乱数が生成される | E-03 | ○ |
| C-02 | コールバック指定時に非同期でキューイングされる | E-04 | ○ |
| C-03 | 非同期完了後にコールバックが呼ばれる | E-10, E-13 | ○ |
| C-04 | buflen=0の場合に正常に処理される | E-01, E-03 | ○ |
| C-05 | buflen=1の場合に1バイトの乱数が生成される | E-01, E-03, E-05 | ○ |
| C-06 | 大きなバッファサイズで乱数が生成される | E-01, E-05 | ○ |
| C-07 | reqのフィールドが正しく初期化される | E-04 | ○ |
| C-08 | buflenが0x7FFFFFFFを超える場合にUV_E2BIGが返る | E-01 | ○ |
| C-09 | flagsが0以外の場合にUV_EINVALが返る | E-02 | ○ |
| C-10 | flagsが大きな値の場合にUV_EINVALが返る | E-02 | ○ |
| C-11 | buflen超過+コールバックありでUV_E2BIGが返る | E-01 | ○ |
| C-12 | flags不正+コールバックありでUV_EINVALが返る | E-02 | ○ |
| C-13 | buflen=0x7FFFFFFFちょうどで正常処理される | E-01 | ○ |
| C-14 | buflen=0x80000000でUV_E2BIGが返る | E-01 | ○ |
| C-15 | flags=0で正常に処理される | E-02 | ○ |
| C-16 | flags=1でUV_EINVALが返る | E-02 | ○ |
| C-17 | buflenチェックがflagsチェックより先に評価される | E-01, E-02 | ○ |
| C-18 | プラットフォーム固有の乱数生成バックエンドが呼ばれる | E-05 | ○ |
| C-19 | Apple/OpenBSDでgetentropy失敗時にdevurandomフォールバック | E-06 | ○ |
| C-20 | Linux/FreeBSDでgetrandom失敗時にdevurandomフォールバック | E-07 | ○ |
| C-21 | Linuxでdevurandomアクセスエラー時にsysctlフォールバック | E-08 | ○ |
| C-22 | UV_EACCESエラー時にsysctlフォールバック | E-17 | ○ |
| C-23 | UV_EIOエラー時にsysctlフォールバック | E-17 | ○ |
| C-24 | UV_ELOOPエラー時にsysctlフォールバック | E-17 | ○ |
| C-25 | UV_EMFILEエラー時にsysctlフォールバック | E-17 | ○ |
| C-26 | UV_ENFILEエラー時にsysctlフォールバック | E-17 | ○ |
| C-27 | UV_ENOENTエラー時にsysctlフォールバック | E-17 | ○ |
| C-28 | UV_EPERMエラー時にsysctlフォールバック | E-17 | ○ |
| C-29 | switch文に含まれないエラーではフォールバックしない | E-08 | ○ |
| C-30 | ワーカーでuv__randomが呼ばれreq->statusに結果格納 | E-09 | ○ |
| C-31 | container_ofでuv_random_tが正しく取得される | E-09 | ○ |
| C-32 | 正常完了時にコールバックがstatus=0で呼ばれる | E-10, E-11 | ○ |
| C-33 | uv__req_unregisterが呼ばれリクエスト登録解除される | E-12 | ○ |
| C-34 | キャンセル時にstatus=UV_ECANCELEDで呼ばれる | E-10 | ○ |
| C-35 | uv__randomエラー時にstatusにエラーが反映される | E-10, E-11 | ○ |
| C-36 | status!=0の場合にreq->statusが無視される | E-11 | ○ |
| C-37 | status==0の場合にreq->statusが使用される | E-11 | ○ |
| C-38 | UV__WORK_CPUタイプとしてワークキューに投入される | E-14 | ○ |
| C-39 | 同期モードでバッファに乱数データが書き込まれる | **根拠不足** | △ |
| C-40 | 連続2回の呼び出しで異なる乱数が生成される | **根拠なし** | △ |

## 4) 不足情報（Unknown / Missing）
- C-39: バッファに実際にデータが書き込まれることは、プラットフォーム固有のバックエンド実装（unix-misc, win-miscモジュール）に依存しており、src/random.c単体からは間接的にしか確認できない
  - 候補：各プラットフォームバックエンドの実装確認 / 統合テストでの検証
- C-40: 乱数の一意性は確率的な性質であり、コードの構造からは保証されない。理論上、同じ値が返る可能性もある
  - 候補：統計的テスト / 十分なサンプルサイズでの実行テスト

## 5) リスクフラグ（レビュー観点）
- 0: 低リスク - パブリックAPI（uv_random）の入力バリデーション（buflen, flags）のテストケースは十分にカバーされている
- 0: 低リスク - 同期/非同期の両モードに対するテストケースが網羅されている
- 1: 中リスク - プラットフォーム固有のフォールバック処理は条件コンパイルで分岐するため、単一プラットフォームでは全パスのテストが困難
- 0: 低リスク - uv__random_done内のステータス優先度ロジックは明確にテストされている
- 1: 中リスク - static関数（uv__random, uv__random_work, uv__random_done）の直接テストにはテストフレームワークの工夫が必要

## 6) レビュアーチェックリスト（最小）
- [ ] buflenの境界値チェック（0x7FFFFFFF / 0x80000000）が正しくテストされているか
- [ ] flagsの不正値チェックが網羅されているか
- [ ] 同期モード（cb=NULL）と非同期モード（cb!=NULL）の両方がカバーされているか
- [ ] uv__random_doneのstatus優先ロジック（ワーカーstatus vs req->status）が正しく検証されているか
- [ ] プラットフォーム固有のフォールバックパスが対象プラットフォームで実行可能か確認
- [ ] static関数のテスト方法（関数ポインタ公開、テスト用ラッパー等）が検討されているか
- [ ] C-39, C-40の「根拠不足」項目について、統合テストまたは実行テストで補完するか判断
