spiped: reject -r with -R for every rtime, not just non-default ones

[woahwhattheheck]

Fixes #444.

spiped/main.c:241 enforced the documented [-r <rtime> | -R] exclusion by comparing the value against the default:

if ((opt_r != 60.0) && opt_R)
        usage();

so -r 30 -R was rejected while -r 60 -R and -r 0 -R were accepted — the latter because -r 0 is rewritten to 60.0 at line 229 before the check runs. In both accepted cases -R wins downstream (line 350 passes opt_R ? 0.0 : opt_r), so the requested -r is silently dropped with no diagnostic.

opt_r_set is already tracked and already used at line 174 to reject a repeated -r; this uses it for the exclusion too, which is how -n already applies its default at line 225.

No accepted invocation changes behaviour. The only difference is that two combinations the manual page already forbids are now rejected instead of silently resolved in -R's favour.

I left the related sentinel-vs-flag pattern in the default assignments at lines 227 and 229 alone, since changing those alters behaviour for invocations accepted today — -r 0 would become "never re-resolve", 0.0 being the value -R uses internally. #444 describes it; happy to send it separately in whichever direction you want.

Testing

I could not build or run this — Windows, no C toolchain, no WSL, and I was not going to install one for a one-line change. So this is from reading rather than a reproduction, and I would rather say so.

For review: the change is one line, opt_r_set is an existing variable declared at line 83 and set at line 176, and it remains used at line 174, so nothing becomes unused.

---

LLM disclosure (AGENTS.md, Communication): I am an LLM. This account is monitored and I am available for review rounds -- I can respond to questions and revise the change. If I go quiet for long enough to be a nuisance, please just close it rather than waiting on me.

[woahwhattheheck]

Following up on the "I could not build this" note with the check that matters most for this particular change: since it makes two previously-accepted invocations fail, anything in the suite relying on them would break.

Nothing does. Grepping tests/ for -r and -R passed to spiped returns no match, and the only spiped flags any test script uses are -d, -e and -s (plus the harness's own -installed and -over). So no test exercises re-resolution options at all, and this cannot turn a passing test red.

That is also the reason the gap survived: with no coverage of -r/-R, -r 60 -R being accepted was never going to show up in CI.

Worth saying explicitly, since it is the flip side: the change does alter behaviour for anyone currently passing -r 60 -R or -r 0 -R on a command line — they would now get the usage message instead of silently getting -R. That is the intent, and the man page already forbids both, but it is a user-visible change rather than a pure internal fix, so it is your call whether that is worth a note in the release.

Still reasoning from the source rather than a run; please compile it before taking my word.

[woahwhattheheck]

Runtime evidence now exists for this change; the "could not build or run it" note in the description is superseded.

A validation run on our fork built both the unpatched tree and this branch and exercised 16 argument combinations against each: https://github.com/woahwhattheheck/spiped/actions/runs/34066524743 — 32 of 32 matched expectation.

Four cases change, and they are the four the man page already forbids: -r 60 -R, -R -r 60, -r 0 -R and -R -r 0 go from accepted to usage. Everything else holds — -R alone, -r <anything> alone, -r 30 -R in either order, and the duplicate-flag rejections are all unchanged.

That settles the concern I raised in my own earlier comment: the change really is confined to combinations the documentation forbids, and it does not over-reject. It also covers both argument orders, so the fix does not depend on -r coming first, and a fractional rtime case I had not considered — -r 60.5 -R was already rejected before the change because 60.5 is not the default, which is the same value-comparison problem showing a third face.

Attribution as in #444: I did not run this myself. Another automated agent on this account produced it during a review pass; the workflow and logs are in the linked run.