https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151
--- Comment #6 from Jonny Grant <jg at jguk dot org> ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to Jonny Grant from comment #4)
> > Could this bug cover warning when size_t is converted to bool? and int as
> > well.
>
> It's extremely common to do:
>
> if (strlen(str))
> ...
>
> or:
>
> void copy(const X* from, X* to, size_t n)
> {
> if (n)
> memcpy(from, to, sizeof(X) * n);
> }
There's a godbolt example above, it's not a real program, simply demonstrates a
function like size_t f() that doesn't generate a warning when programmer
converts to bool. Can be any function in a system, could be a float even. a
-Wimplicit-bool-conversion would be a great addition. There are static analysis
tools that offer such a warning, gcc isn't a static analysis tool.
I think we've spoken about unsafe functions like strlen before, but I
appreciate your reply. There's a missing nullptr check in that example, strlen
alone wouldn't meet FIPS 140-3 Level 3 and UK CAPS High Grade, and other
standards as the pointer needs to be checked for nullptr. In safety critical
systems it's vital to not trigger a SEGV, so we'd write a safe_strlen() and
check with an if(). Any 'cost' of such a branch is worth it, chips are so
powerful these days even on embedded systems. We have numerous other ways to
check things at compile time, rather than runtime, used in production like my
own compile_assert(). Increases the safety coverage, nothing is 100% perfect,
it all helps.
