balazske added a comment. Probably we have different pre-conceptions about this checker. One thing is to discover the error by finding a violated precondition or other bug that is caused by the wrong return value of the called and failed function. This is case (1) above if I am correct. Other way is to discover the error by checking the state of an object that a function manipulates and find use of the object when it is in bad state. This is the case (2) above if I am correct. These are things that are done by other checkers partially already now. Case (1) is job of `StdLibraryFunctionsChecker` or other checkers, maybe any check for use of zero pointers. Case (2) is job of `StreamChecker` and similar checkers that maintain state of some object or "handle". For many of the functions in ERR33-C no such checker exists yet and it would be very much work do make all of these (or not possible at all).
This change is doing another approach: It checks directly the value that is returned from a function that may fail, not the object that the function manipulates. The goal is to check if the return value of a function is checked in the code. This may be discovered when the value is passed to a next function call and the precondition of that function is violated but this is not the goal of this checker. It tries to find an execution path where the returned value is used in the code in a way that is said to be an //error check//, or in a way that is an //other use//. The //error check// is discovered by checking the statement where the value appears to discover if it is compared against an error code (specific to the called function that produced the value). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D72705/new/ https://reviews.llvm.org/D72705 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
