ConversionChecker produces false positives when it encounters the
idiomatic usage of certain well-known functions (e.g. getc() and the
character classification functions like isalpha()). To eliminate these
false positives, the analyzer needs some information about semantics of
these functions. This functionality have been implemented already in
StdCLibraryFunctionsChecker, so we simply load that automatically when
ConversionChecker is loaded.
Details
- Reviewers
george.karpenkov NoQ
Diff Detail
- Repository
- rC Clang
- Build Status
Buildable 22983 Build 22982: arc lint + arc unit
Event Timeline
test/Analysis/conversion.c | ||
---|---|---|
158 | And this one |
Maybe just move StdCLibraryFunctionsChecker to core? (.apiModeling?) We officially don't support disabling core, so i guess it kinda solves the issue. Also all of our languages are C-based, these functions are present on all platforms (if any of those aren't, we could split them out and keep in unix).
Yes, moving StdCLibraryFunctionsChecker to an always-loaded package is probably a better solution than adding this one particular dependency link. (Evaluating these functions may be useful for other checkers as well, although it does not seem to change the results of other regression tests.) As an alternative to moving this checker to either the core or the apiModeling package, we could add unix.StdCLibraryFunctions to the dozen or so loaded-by-default checkers listed in lib/Driver/ToolChains/Clang.cpp without moving it to a different package. Which of these options is the best?
As far as i understand, these driver-controlled thingies are for platform owners to be able to say "hey we clearly don't want this checker to be turned on on our platform". As long as there's no indication of that sort of issue, we should instead keep it all in one place, which is Checkers.td. It's already hard enough to figure out which checkers are on by default by looking at the list of checkers.
I submitted a new patch, which moves stdCLibraryFunctions to apiModeling (https://reviews.llvm.org/D52722).
I think this comment is no longer relevant ^-^