Zig: a library with no product binary is asked for a ReleaseSafe build; an AFL packaging shim is a C fuzz target; setup-zig without `version` installs build.zig.zon's minimum_zig_version; `zig build fuzz` / `zig build test --fuzz`

オープン
  • 何か問題がありますか？
#288 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
30/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
c, python
領域
build-system, ci-cd, testing-qa

調査の方向性

Start in ecosystems/zig.py, where _EXECUTABLE matches any addExecutable call and _read_programs treats that as a binary, so library build.zig files that only build examples or benchmarks wrongly pass the hardening check. The C/C++ fuzz-testing check also counts a comment-only __AFL_LOOP in pkg/afl++/afl.c as a fuzz target. Reproduce each with a minimal build.zig or .c fixture before changing anything. The Zig platform-matrix and fuzz gaps need a design decision first, so this is not a good first pick.

索引モデルが issue の本文から書いたものです。

説明

http.zig and libxev: hardening FAIL "release builds drop Zig's safety checks: no ReleaseSafe build" although the only addExecutable calls build examples and benchmarks (a library has no binary to harden → SKIP). ghostty: fuzz-testing counts its AFL++ packaging shim (a manual expansion of AFL's macros) as a C/C++ fuzz target. zig-clap, zls, libxev, ghostty: "1 Zig version (default)" while mlugg/setup-zig with no version installs build.zig.zon's minimum_zig_version. tigerbeetle: fuzz-testing SKIPs "not applicable to Zig" though Zig projects fuzz with zig build fuzz and, since 0.14, zig build test --fuzz / std.testing.fuzz.

Evidence from the corpus audit

karlseguin/http.zig (also mitchellh/libxev) / hardening
  • kind: FALSE_POSITIVE
  • actual: FAIL: release builds drop Zig's safety checks: no ReleaseSafe build
  • expected: SKIP: "a library has no binary to harden" — the only addExecutable calls build the examples (and, in
    libxev, the benchmarks).
  • evidence: http.zig build.zig:81-83: for (examples) |ex| { / const exe = b.addExecutable(.{ / .name = ex.name,
    with .file = "examples/04_action_context.zig" entries at :70-78; libxev build.zig:194 ("src/bench/{s}" at
    :197-200), :244 and :259 ("examples/{s}"). Validator: ecosystems/zig.py:_EXECUTABLE = re.compile(r"\baddExecutable\s*\(") and _read_programs -> any match means "executable".
  • repro: build.zig whose only addExecutable has .root_source_file = b.path("examples/x.zig").
  • confidence: medium
ghostty-org/ghostty / fuzz-testing
  • kind: FALSE_POSITIVE
  • actual: FAIL: C/C++: fuzz targets in 1 file(s), but no CI configuration runs a fuzz target binary ...
  • expected: "no fuzz targets found" for C/C++: the one match is Ghostty's packaging shim for AFL++ (a manual expansion
    of AFL's macros), not a product fuzz target.
  • evidence: pkg/afl++/afl.c:14: // expand the AFL macros (__AFL_INIT, __AFL_LOOP, __AFL_FUZZ_INIT, etc.) and;
    :102: // Manual expansion of __AFL_LOOP(UINT_MAX) — persistent mode loop. (the only file matching
    LLVMFuzzerTestOneInput|__AFL_LOOP outside .git).
  • repro: a .c file whose only __AFL_LOOP is in a comment.
  • confidence: low
Hejsil/zig-clap (also zls, libxev, ghostty) / platform-matrix
  • kind: UNSUPPORTED
  • actual: FAIL: CI covers ... 1 Zig version(s) (default)
  • expected: n/a (gap): mlugg/setup-zig with no version input installs the minimum_zig_version of build.zig.zon,
    so "default" is a known version the validator could read from the manifest.
  • evidence: .github/workflows/main.yml:14-16: - uses: mlugg/setup-zig@v2 / with: / cache-key: ${{ matrix.optimize }}
    (no version); build.zig.zon:4: .minimum_zig_version = "0.18.0-dev.954+60635c2bd",.
  • repro: unclear (tool semantics)
  • confidence: low
tigerbeetle/tigerbeetle / fuzz-testing
  • kind: UNSUPPORTED
  • actual: SKIP: not applicable to ... Zig
  • expected: n/a (gap): Zig projects fuzz with a build step (zig build fuzz) and, since Zig 0.14, zig build test --fuzz / std.testing.fuzz; the profile knows no Zig fuzzer, so TigerBeetle's fuzzers and VOPR are invisible.
  • evidence: build.zig:168: .fuzz = b.step("fuzz", "Run non-VOPR fuzzers"),; :440-441:
    // zig build fuzz -- --events-max=100 lsm_tree 123 / build_fuzz(b, .{; :646:
    build_ci_step(b, step_ci, .{ "fuzz", "--", "smoke" }, ...). Docs: docs/ecosystems/zig.md "no ... fuzzer ... the
    validator knows reads Zig".
  • repro: unclear (tool support)
  • confidence: low

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

主要言語
Python
スター
4
フォーク
1
平均マージ
10時間 41分
マージ済み PR（30日）
79

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

cpp-best-practices/project_validator のほかの issue

cpp-best-practices/project_validator の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。