https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120213
--- Comment #9 from Raffaello Bertini <raffaellobertini at gmail dot com> --- (In reply to David Malcolm from comment #8) > I'm not sure I fully grok the example code, but FWIW the analyzer doesn't > yet "know" about the behavior of strnlen and so conservatively assumes any > possible size_t value as the output. There are also limitations in the > current internal representation that prevent various useful reasoning about > string operations, so it might be running into that. I see. That make sense, as it has esplicitly shown the path with the input string "H" it might even not look correct, or over-analyzing the code. Beside the analyzer output is always the same independently of the input string and that's correct. but yeah it looks like it is failing to understand that at some point the recursion will return the 'l' var < NUM_CHARS and won't go to read outside the stack. Basically is following the 'true branch' assuming l > NUM_CHARS when effectively l is <= NUM_CHARS. Btw at the moment the only way to "fix it" is to wrap the function in pragmas to ignore the analyzer warning? or there are some extra directive to help the analyzer "understand" the code?
