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.
