Reply To cazfi
I assume these to be some common pattern to be fixed as one bug.
The pattern is that there's a sg_failure_ret() macro checking that the string is not NULL, and then separate sg_failure_ret() macro using strlen() to check its length. Seems correct to me, i.e., the report to be a false positive.
Reply To cazfi
Reply To cazfi
I assume these to be some common pattern to be fixed as one bug.
The pattern is that there's a sg_failure_ret() macro checking that the string is not NULL, and then separate sg_failure_ret() macro using strlen() to check its length. Seems correct to me, i.e., the report to be a false positive.
Even more generic pattern: sg_failure_ret() macro checking something that should make sure that some latter code should not trip to NULL pointers or similar.
The problem with current sg_failure_ret() is in the order it does things in case of failure:
1. It sets sg_success to FALSE
2. It calls logging function
3. (via sg_check_ret() ) it returns if sg_success is FALSE
The problem here is that compiler/analyzer cannot be sure that the logging function call does not alter sg_success back to TRUE, and thus make sg_check_ret() to let execution to continue.
Clang analyzer gives some warnings about strlen() being called with NULL string in savegame2.c and savegame3.c. I assume these to be some common pattern to be fixed as one bug.