#704 GTK3V2MAIN track.c: DrawEndPt visibility-mismatch dispatch -- 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/track.c:3133 and :3148 -- inside DrawEndPt(), two branches clang-tidy flags as clone candidates.
Deliberately NOT merged: track-visibility and layer-visibility are independent conditions that can both be true simultaneously; merging would need reordering relative to the real-drawing branches nearby and could pick the wrong one for a hybrid visibility case. This ticket exists purely to track the decision (per project policy: leave-alone findings get a ticket) so it doesn't keep resurfacing as 'new'. No fix planned. A regression/visual fixture exercising a track with a visible track but hidden layer (or vice versa) at an endpoint would give this real coverage if anyone later touches this function.
Discussion
Anonymous
Diff:
Investigated. DrawEndPt() (track.c:3106-3160) checks the track-own-visibility axis (branches at 3106/3133) before the layer-visibility axis (3135/3145) as a priority
chain. When the two axes disagree — e.g. trk's own flag says visible but its layer is hidden, while trk1 is the reverse — the own-flag branch fires first and the layer
signal is silently discarded. This is inconsistent with the rest of track.c: DrawTracks's skip logic (193-199, 3219-3221) and HilightElevations (3288-3295) always
compose the two axes independently (AND/OR), never as a priority chain. Also worth noting: in the normal draw path DrawTracks already skips any track whose own layer is
hidden before calling DrawTrack, so in practice the only real unknown at this point is trk1's layer state.
Fix: gate branches 1-2 on trk and trk1 being on the same layer before trusting the own-flag comparison; when layers differ, fall through to the layer-boundary branches
(3-4) instead. Should add a regression case covering all 4 own-flag × layer-visible combinations for trk/trk1, since none currently exist.
Investigated. DrawEndPt() (track.c:3106-3160) checks the track-own-visibility axis (branches at 3106/3133) before the layer-visibility axis (3135/3145) as a priority
chain. When the two axes disagree — e.g. trk's own flag says visible but its layer is hidden, while trk1 is the reverse — the own-flag branch fires first and the layer
signal is silently discarded. This is inconsistent with the rest of track.c: DrawTracks's skip logic (193-199, 3219-3221) and HilightElevations (3288-3295) always
compose the two axes independently (AND/OR), never as a priority chain. Also worth noting: in the normal draw path DrawTracks already skips any track whose own layer is
hidden before calling DrawTrack, so in practice the only real unknown at this point is trk1's layer state.
the described problem is a cosmetic mis-rendering of an endpoint marker under contradictory track-vs-layer visibility, and it's hard-to-impossible to trigger through the normal draw path because of the upstream layer skip — a latent inconsistency rather than a live bug. If you want, I can construct the exact trk/trk1 visibility+layer state table (all four own-flag × layer combos) that a regression fixture would need, so the ticket carries a concrete repro recipe instead of leaving it abstract.
Added a NOLINTNEXTLINE(bugprone-branch-clone) suppression at the two flagged lines in track.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.
Note: the exact flagged lines shifted slightly from your original investigation (own-visibility/layer-visibility priority-chain branches, same mechanism you described) due to unrelated edits earlier in the file from SF #732 -- confirmed the real current locations via a direct clang-tidy run rather than assuming the original line numbers still applied.
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).