#703 GTK3V2MAIN cprofile.c: pathMatch tie-break chain -- bugprone-branch-clone, intentionally not merged
Found triaging clang-tidy's bugprone-branch-clone Phase D (see .claude/phase-d-branch-clone-remaining-plan.md and the original SF #699/commit 18a1d00e first slice, which named this same site). app/bin/cprofile.c:988 and :990 -- the pathMatch tie-break chain has two pairs of identical-looking branch bodies (rc0=1) clang-tidy flags as clone candidates.
Deliberately NOT merged: verified by reading the full chain that merging either the pathMatch=1 pair or the pathMatch=2 triple would change which branch wins when trkN==pathStartTrk && trkN==pathEndTrk (both conditions true simultaneously) -- a real ordering/tie-break dependency, not duplicate code. This ticket exists purely to track the decision (per project policy: leave-alone findings get a ticket, not just a code comment) so it doesn't keep resurfacing as 'new' in future clang-tidy triage passes. No fix planned. A regression fixture exercising the pathStartTrk==pathEndTrk simultaneous-match case would give this real test coverage if anyone later touches this function -- currently believed untested.
Discussion
Anonymous
Diff:
Investigated. The tie occurs in ProfileShortestPathFunc(), SPTC_MATCH case (cprofile.c:983-1001): when a multi-endpoint track (e.g. a turnout) already anchors both
pathStartTrk and pathEndTrk via two of its endpoints, and the search reaches it again via a third endpoint that matches neither pathStartEp nor pathEndEp, line 992-993
hardcodes pathMatch = 2 (extend-End). That breaks the "start wins" precedence used consistently everywhere else in the same function (the exact-match pair at 988/990 and
the fallback at 994/996 both check pathStartTrk first). Not data-corrupting — pathStartEp/pathEndEp stay independent even when the tracks coincide — but it's an
inconsistency, not an intentional exception (introduced in a single 2022 commit, no comment explaining the reversal).
Fix: change line 993 from pathMatch = 2; to pathMatch = 1; so start-wins-ties holds uniformly.
This is a rare edge case. It requires a turnout where two endpoints are connected. If the pathfinder hits that turnout again by the third endpoint it is unclear whether this leads to extend-start or extend-end.
I can see no simple way to create that via the UI.
Added a NOLINTNEXTLINE(bugprone-branch-clone) suppression at the two flagged lines in cprofile.c (referencing this ticket and your investigation) so this won't keep re-flagging on future clang-tidy scans. Verified empirically by re-running clang-tidy on the file after the change -- both findings are gone.
Bundled into the same branch as SF #732 (bugprone-assignment-in-if-condition hoisting): Hg branch bug-732-assignment-in-if-hoist-gtk3, git PR https://github.com/adbyrne/XTrkCAD/pull/133 (CI running).