[Bug c++/80151] Add a warning to catch implicit string to bool conversion (-Wstring-conversion)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonny Grant from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> 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,

And a missing declaration of str, and a missing function declaration because
'if' statements aren't valid at file scope. And '...' isn't a valid statement.
Clearly it was not a complete example.

Feel free to assume the 'if (strlen(str))' comes after code that already
ensured it's not null.

> 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.

This seems entirely irrelevant to what you're replying to. I simply pointed out
that it's extremely common to test size_t values (and other integer values) in
boolean contexts. That one line wasn't intended to meet functional safety
requirements.

> 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.

You seem to be completely missing the point: warning every time an integer is
converted to bool would generate a huge number of warnings for perfectly safe
code. Drowning users in bogus warnings does not improve safety.

If you want a new warning for those cases, it needs to be properly described to
say when it should warn *and when it should not*, to avoid unhelpful warnings
for the cases like comment 5 and comment 7.