https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80151
--- Comment #9 from Jonny Grant <jg at jguk dot org> --- (In reply to Jonathan Wakely from comment #8) > (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. Your example isn't related to my comment #4. > > 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. Your comment isn't relevant. > > > 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. You've missed the point. It's safety critical software. Written in C. (We're not using ADA, or Rust for this project). I suggested a warning addition. We Hence comment #4 request. Functional safety mandates we pay attention to potential issues, hence the interest in implicit conversions. It's not a user support forum, it's a PR. > 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. Comment #4 covers the implicit conversion request. I get that you don't want that; we do, we need to know.
