balazske added a comment. About the questions:
- How many issues does it raise? Would we flood the user? I did not experience that the checker produces many warnings. Any warning from this checker is connected to a function call of a standard API, and the number of such calls is usually not high. Typically one problem which the checker reports can occur often in a specific program, for example the `fileno` case (fileno returns -1 at failure, often this failure is not handled and value -1 is used as a file number). This should not be a case of hundreds of warnings. - How "interesting" those issues are? Do they have *actual* value for the user? (Not only niece edge-cases, that is fancy to know about, but actual users would genuinely commit such mistakes) If the coder cares about all edge-cases of API calls, these are real and important issues. More often most of the results are just cases of ignored errors that are very rare, the programmer probably intentionally did not handle these because it is not worth for a such rare situation. From security point of view these cases can be used to find places where it is possible to make an API call (which normally "never" fails) intentionally fail and produce unexpected behavior of the program. So for an average application many results are not very important, for stability and security critical code the results can be more important. - How long those bug-paths are in practice? I'd argue, the longer they are, usually the less actionable they are for the user. Less actionable reports are also less valuable, or even harmful. The bug path can be long, often only the very last part is important, but sometimes not. - In general, how understandable these reports are? Do we have all the interesting "notes" or "events" on the path? These should be not more difficult to understand than a division by zero, only with a function call instead of division. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D152436/new/ https://reviews.llvm.org/D152436 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
