On Tue, Oct 27, 2026 at 08:51:18AM +0100, Heinrich Schuchardt wrote: > 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.
That's how we should handle it yes, mark it false positive in Coverity. Thanks Heinrich! -- Tom
signature.asc
Description: PGP signature
