Repository navigation
pass_similarity calls qsort with a null base for an empty fingerprint set #1367
Description
What happens
collect_fp_entries() starts with entries == NULL and calls
qsort(entries, count, ...) unconditionally. When a graph buffer has no
Function/Method nodes with fingerprints, count == 0, so the call is
qsort(NULL, 0, ...).
The project targets C standards where the sorting API is specified in terms of
base pointing at an array. Zero elements suppress comparator calls, but do not
make a null base a portable array pointer. Sorting is also unnecessary for the
one-entry case.
Proposed fix
Call qsort only when count > 1. This preserves deterministic ordering for
the only case that needs sorting and avoids passing an empty null buffer into
the C library.
Scope
src/pipeline/pass_similarity.c- no behavior change for two or more entries
- no new dependency or API change
Validation
The focused sanitizer-backed simhash suite passes: 24 tests.
Activity
DeusData commentedon Aug 3, 2026
Thank you for catching this undefined-behavior edge case. Calling
qsortwith a null base even when the count is zero is unnecessary and can fail under stricter runtimes or tooling. I have routed it at high priority in0.9.1-rc; PR #1368 is the focused fix track and should bind the change with the empty-fingerprint regression case.DeusData commentedon Aug 4, 2026
Fixed on main by #1368 (commit 5178cde, merged as b6fe834) — thanks again for both the precise report and the fix. Follow-up on our side: the empty-fingerprint path can only be bound by a trap-on-UBSan build (no C-level assertion can observe the violation), so we'll add that binding in the sanitizer lane.
Merge pull request #1476 from DeusData/test/1367-empty-graph-regression
test(similarity): cover the empty-graph qsort null base (DeusData#1367)