style(mcp): compare nullable strings through one helper

[SarletteD]

What does this PR do?

Two comparators in src/mcp/mcp.c break ties with one strcmp after another, each call spelling out
x ? x : "" fallbacks inline: project_record_compare (name, root path, database file) and
search_result_cmp (score, qualified name, file, then lines). cppcheck 2.20, the version _lint.yml pins,
reports knownConditionTrueFalse on them ("by_root != 0 is always false", "file_order != 0 is always
false"), although neither function differs between these trees: whether it fires depends on the rest of the lint source
list. Both comparators now call nullable_strcmp(), which orders NULL like "" exactly as the inline
fallbacks did. Comparison order and results are unchanged for every input.

With cppcheck 2.20.0 built from source, main itself already fails lint-cppcheck on search_result_cmp
(table below); the upstream CI job may or may not hit the same path. It is also a prerequisite for the Structured Text stack (four stacked PRs; the first one is linked in a comment once it is open), which is stacked on it: with the ST
grammar and sources in the tree, lint-cppcheck turns red on src/mcp/mcp.c, a file the stack does not
touch. It is sent on its own because it is a fix, not part of the feature (CONTRIBUTING.md, "Don't mix
features with fixes").

Reproduction (scripts/lint.sh --ci, clang-format 20.1.8, cppcheck 2.20.0)

Tree	lint-cppcheck
upstream main @ 64c23fa	fails: mcp.c:12614 Condition 'file_order!=0' is always false [knownConditionTrueFalse] in search_result_cmp
+ the first Structured Text PR (grammar, lang_specs.c, extraction)	fails: mcp.c:2734 Condition 'by_root!=0' is always false [knownConditionTrueFalse] in project_record_compare
upstream main + only project_record_compare rewritten (one variable carrying the order)	fails: mcp.c:12613 Condition 'file_order!=0' is always false in search_result_cmp
both comparators rewritten that way, under the ST stack up to its third PR	fails: mcp.c:2731 Variable 'order' is assigned an expression that holds the same value [redundantAssignment]
this PR (helper), alone and under every PR of the ST stack	passes

The findings are false positives: each flagged strcmp compares different fields. Routing the
comparisons through one helper removes the inline ternaries the analyzer reasons about.

Scope

• In: src/mcp/mcp.c only, nullable_strcmp plus its two callers (+10 / -6 lines).
• Out: any other cppcheck configuration change; no suppression was added.

Commit

• style(mcp): compare nullable strings through one helper

Checks

• ./build/c/test-runner mcp: rc 0 (126 PASS lines)
• scripts/lint.sh --ci (clang-format 20.1.8, cppcheck 2.20.0): rc 0; also rc 0 on every PR of the ST stack on top of it
• make -f Makefile.cbm lint-tidy-diff (clang-tidy 21.1.6, diff against main): rc 0

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (see Checks)
• Lint passes (scripts/lint.sh --ci)
• No behaviour change, so no new test; the reproduction above is the evidence

Written with Claude Code (Anthropic) on behalf of @SarletteD, who reviewed and signs off every commit.

[SarletteD]

The first PR of the Structured Text stack that builds on this one is #2397 (refs #1810). Written with Claude Code (Anthropic) on behalf of @SarletteD.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Merged. Thank you, @SarletteD! This is a model of how to handle an analyzer false positive: refactor rather than suppress, with a reproduction table showing exactly which tree trips which finding. Each of the five replaced comparisons is the same expression as before (nullable_strcmp(x, y) is strcmp(x ? x : "", y ? y : "") with the arguments in the same order), and all five fields are char *, so the NULL guards were live and are preserved. We also checked it against the 38 other open PRs touching src/mcp/mcp.c: none collides with these hunks, so it costs nobody a rebase. On to the Structured Text stack!