UBSan: memcpy with null pointers in TbrSnapshot save/restore (ts_tbr.cpp)

[ms609]

The gcc-ASAN workflow passes, but its log carries 12 UBSan
nonnull-attribute reports, all from the same pair of methods:

ts_tbr.cpp:356:16: runtime error: null pointer passed as argument 1, which is declared to never be null
ts_tbr.cpp:356:16: runtime error: null pointer passed as argument 2, which is declared to never be null
ts_tbr.cpp:357:16: ...
ts_tbr.cpp:370:16: ...
ts_tbr.cpp:371:16: ...
ts_tbr.cpp:372:16: ...

Observed in run 30994944304 (job "AddressSanitizer tests").

Cause

TbrSnapshot::save() and ::restore() (src/ts_tbr.cpp:352-380) call
std::memcpy on std::vector::data(). When the vector is empty, data() may
return nullptr and the size is 0. memcpy(nullptr, nullptr, 0) is
undefined behaviour by the letter of the standard — memcpy's parameters
carry nonnull — even though every real implementation is a no-op.

The lines that report are the state_bytes and cost_bytes copies, which are
reached whenever a dataset yields zero-length state or cost arrays.

Why it is low severity

Benign in practice on every toolchain the package targets; nothing
miscompiles today. But it is real UB, it is the only remaining noise in an
otherwise clean sanitizer run, and a compiler is entitled to infer from the
nonnull attribute that the pointers cannot be null and delete a subsequent
null check.

Fix

Guard each copy on a non-zero size, e.g. if (state_bytes) { ... }, or hoist
one guard around the block. Six call sites.

Reopening condition

Closing this as wontfix would need the reports suppressed rather than fixed,
which would hide future genuine nonnull violations in the same file. Reopen
if a sanitizer run shows these lines again after a fix.

Found while making ASan runs clean in
#123; deliberately not widened into that PR.

[ms609]

Claimed. Working on branch feature/tbr-memcpy-nonnull, worktree ../worktrees/TS-tbr-nonnull.

[ms609]

Two corrections to my own issue text, for the record:

• The struct is StateSnapshot, not TbrSnapshot.
• The reported lines are 355-357 and 370-372, not 356-372 — I dropped 355 when transcribing. Verified against the job log for run 30994944304 (job 92269667254).

The full reported set is prelim, final_ and local_cost in both save() and restore(). The NA arrays and postorder are not in it, which pins the condition to state_bytes == 0 && cost_bytes == 0 with has_na false.

Cause located and reproduced: it is not constant/autapomorphic data as the issue speculated in passing, but HSJ data whose characters all belong to a hierarchy — the Fitch kernel is then left with nothing, so total_words == 0 and n_blocks == 0. Instrumenting save() and running test-ts-hsj.R reports state=0 cost=0 with data() genuinely null, reached through driven_search() from the existing test "HSJ search handles all-hierarchy data (zero Fitch words)" (tests/testthat/test-ts-hsj.R:940). An all-constant dataset via MaximizeParsimony() does not reach this code — I checked, and it does not fire.

Also checked: the vignettes and examples ASan jobs carry no UBSan reports at all, so ts_tbr.cpp was the whole of it.