[PATCH] D72705: [clang][checkers] Added new checker 'alpha.unix.ErrorReturn'.

Balázs Kéri via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jan 27 08:55:56 PST 2020


balazske added a comment.

I wanted to use the existing infrastructure (ExprEngine) to test what conditions are applied to the function return value. I did not found other way to get this information. So the checker observes what checks are applied to the return value by making assumptions on it. The checker is only designed to detect if specific checks are made on the return value, not what other problems the return value (NULL or -1 or other) can cause, this is handled by other checkers. A problem with this approach is that it works only if the value (the return value of the function) is not constrained already after the function call (at least not for the error value), otherwise it will interpret (wrongly) this constrainment as result of an error check branch in the code. So it is not possible to make a branch with fixed error return value (if other checker do this this is probably bad too). And it is not possible (?) to make a new branch without constraint.

For the first case the checker can be improved probably by detecting that the value usage is before the error check program point. But this is hardly possible to do because the error check code may be split into multiple branches (or `switch` if it is a numerical value) so the check happens not at a single point and we can not be sure if a value access is part of the error check or not.

The second case is not detectable with this kind of checker, unless it is possible to find the values that a conditional branch depends on (to find out that the "dice" call does not depend on the return value of `aligned_alloc`).

The third case can be improved by checking for "escape" of the value to check. Otherwise this should give a false positive now.

Probably it is better to make other checkers for special purposes (because the checker in this version is some "abuse" of the path sensitive analysis and the above mentioned problem). If for many of the listed functions there is checker that verifies validity of the input parameters, or tracks if a special error value was returned from the function or the objects (for example file descriptors) are used without error check. Still some kind of errors are not detectable, for example the `fread` or `strtol` cases.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D72705/new/

https://reviews.llvm.org/D72705





More information about the cfe-commits mailing list