On 10/27/26 08:19, Alexey Charkov wrote:
Hi Tom,
I've checked 661173 and it looks like a false positive - but one that
is likely to reappear going forward.
On Tue, Oct 27, 2026 at 5:27 AM Tom Rini <[email protected]> wrote:
Here's the latest report. Since it says 20 out of 25, I downloaded a
report as well and the 5 not listed here are:
[...]
CID 661173, String not null terminated, boot/bootmeth_bls.c,bls_boot
CID 661173: (#1 of 1): String not null terminated (STRING_NULL)
7. string_null: Passing unterminated string label->name to parse_label_keys,
which expects a null-terminated string.[show details]
309 ret = parse_label_keys(&body, &scratch, label, true);
310 if (ret < 0)
The string it complains about arrives via memdup_nul(), which does (in
lib/string.c:357-358):
dst[len] = '\0';
return memcpy(dst, src, len);
Apparently Coverity misses the assignment of the terminator which
precedes the memcpy call and flags the string as unterminated. Shall
we swap the order of those two operations to keep Coverity happy going
forward? The behavior doesn't change either way, although directly
returning the memcpy result (as it is done currently) looks a bit
neater to me.
Best regards,
Alexey
Hello Alexey,
I marked the Coverity ID as false positive. I am not sure if Coverity
would understand a changed sequence. A tail call results in shorter
binary code length. I would keep it.
Best regards
Heinrich
