feat(xce-test-rc-file): task 1.2 rc-file line-loading via pluggable runner
Adds rcfile_load(path, runner) to rcfile.c/rcfile.h: reads lines with getline() (no fixed-size buffer, so a long line like a multi-peer `set masters ...` can never be silently truncated or split), strips the trailing newline, invokes the caller-supplied runner once per line, and stops at the first nonzero runner return, propagating that value. A missing rc file is a silent no-op; any other open failure prints one stderr warning and returns 0. Found during GREEN: fopen() succeeds on a directory path on this platform, so the EISDIR failure only surfaces on the first getline() call (ferror(f) set) -- added a post-loop ferror() check to catch it (bug-1716). 5 new unit tests (11 total with task 1.1): ENOENT-silent, per-line-in-order with newline stripped, stop-on-nonzero with exact propagation, non-ENOENT open-failure warning, and a >4KB single line proving no truncation/split. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AgYRU3zDTqNGV5Jk8aiKLg
This commit is contained in:
parent
b3c462ede4
commit
77aba21fb0
4 changed files with 305 additions and 6 deletions
|
|
@ -9,7 +9,7 @@
|
|||
- Observable: a unit test run demonstrates the correct location is chosen for each of the three environment combinations above, and a subsequent unrelated test's own `$HOME`/`$XDG_CONFIG_HOME` reads are unaffected
|
||||
- _Requirements: 1.1_
|
||||
|
||||
- [ ] 1.2 Implement rc-file line-loading with a pluggable command runner, with unit tests
|
||||
- [x] 1.2 Implement rc-file line-loading with a pluggable command runner, with unit tests
|
||||
- Read the rc file line by line using `getline()` (no fixed-size buffer), invoking a caller-supplied runner once per line with the trailing newline removed
|
||||
- Treat a missing rc file as a no-op success (no error), and a present-but-unreadable rc file as a non-fatal warning that still allows startup to proceed
|
||||
- Stop reading immediately the first time the runner signals a stop, and propagate that signal to the caller without processing any remaining lines
|
||||
|
|
@ -53,3 +53,10 @@
|
|||
- Observable: the existing scripts' outcomes are unchanged, demonstrating this feature introduces no regression for callers that know nothing about it
|
||||
- _Requirements: 1.3_
|
||||
- _Depends: 2.2_
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
- Task 1.1: `controller_unit_test` can silently die with exit code 1/2 before reaching later-registered test groups if `/tmp` fills up — a pre-existing, already-tracked leak (bug-924) where test fixtures under `/tmp/xce_*` aren't cleaned up across many prior sessions' runs can exhaust disk and make `mkdtemp()` in unrelated tests (e.g. `test_repl_apply.c`) `exit(1)` on `ENOSPC`. If a later task's `controller_unit_test` run dies early or shows an unexplained failure in an unrelated file, check `df -h /tmp` before assuming a regression in this task's own code.
|
||||
- Task 1.1: the 2 pre-existing `test_config_repl.c` failures (`test_conf_trim_keeps_only_n_versions`, `test_conf_get_saved_tag_no_config`) are the tracked `bug-1561` overlayfs-artifact regression, unrelated to this spec — expect them to keep appearing in every subsequent task's `controller_unit_test` run; do not treat them as a new regression.
|
||||
- Task 1.2: `fopen()` succeeds on a directory path on this platform's glibc — the EISDIR failure only surfaces on the first `getline()` call (`errno=EISDIR`, `ferror(f)` set). A naive `if (!f)` open-failure check misses this; a post-loop `ferror(f)` check is required to catch it (see `rcfile_load()`, bug-1716).
|
||||
- Task 1.2: an ASAN heap-use-after-free was observed ONCE in an ad-hoc standalone `controller_unit_test` run (`commit_resolve_pending`/`fsync_worker`/`tap_teardown` in `test_apply_pump.c`) — did not reproduce on a second run or in the canonical `xce-build.sh` run. Unrelated to this spec's files; logged as bug-1717 (unreproduced flake) for tracking. If it recurs on a later task's run, capture the full ASAN report before assuming it's this spec's fault.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue