This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] LibraryFunctions: Fix errors due to different integral types and typedefs on different architectures.
ClosedPublic

Authored by NoQ on Oct 25 2016, 6:36 AM.

Details

Summary

The mechanism for filtering out wrong functions with the same name was too aggressive to filter out eg. int vs. long, when sizes of both are equal. Such issues were detected by several buildbots.

In fact, our function summaries are not precise enough to deal with such differences, and they do not need to be. This patch fixes the issue by only taking size and signedness into account. Also minor cleanups.

Diff Detail

Event Timeline

NoQ updated this revision to Diff 75695.Oct 25 2016, 6:36 AM
NoQ retitled this revision from to [analyzer] LibraryFunctions: Fix errors due to different integral types and typedefs on different architectures..
NoQ updated this object.
NoQ added a subscriber: cfe-commits.
dcoughlin edited edge metadata.Oct 25 2016, 4:53 PM

Are the parameter types actually needed? I think in general the rest of the analyzer uses arity alone.

Is the idea to allow for overloads in C++? If so, then I think this equivalent-up-to-size-and-sign approach will disallow those overloads.

lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
400

Maybe this should be named something like "typesMatch" since it is not actually return whether the types are equal?

425

If the problem is only for ssize_t, would it make sense to only do this if both the lhs and rhs are signed?

Another possibility is to have an lhs of what we think is the ssize_t type match any signed type.

NoQ updated this revision to Diff 76031.Oct 27 2016, 7:42 AM
NoQ edited edge metadata.
NoQ marked 2 inline comments as done.

Are the parameter types actually needed? I think in general the rest of the analyzer uses arity alone.

Arity checks are to avoid crashes getArg...(). I'm also avoiding assertion failures on APSInt manipulations, which must be of the same type. And even if APSInts didn't assert-fail and were promoted correctly automatically in all operations, we would still want to avoid mismatching types, because results may be completely unexpected.

All right, yep, i'm getting the point about overrides. It's true that we need to find the correct functions better, rather than match more functions. Trying that in the new revision.

zaks.anna edited edge metadata.Oct 28 2016, 5:55 PM

How about this imperfect solution that will work quite well in practice? For the ssize_t case, where type size cannot be used, we check the function name, # of arguments , and check that the functions are coming from the system header.

NoQ updated this revision to Diff 76641.Nov 1 2016, 3:34 PM
NoQ edited edge metadata.

Try out a completely different approach which was also suggested by Anna.

Allow providing multiple variants of summaries for each function identifier, with different type specifications and branches. This way we preserve type checks and support overloads fairly well, however we introduce a bit of summary data duplication. This solves the ssize_t problem by providing multiple variants for every summary that uses it: one summary for the case when ssize_t is int, one for the case when it's long, one for the case when it's long long.

Please, explain what variants are for in comments.

zaks.anna accepted this revision.Nov 2 2016, 8:59 AM
zaks.anna edited edge metadata.

LGTM other than the missing explanation in comments.

This revision is now accepted and ready to land.Nov 2 2016, 8:59 AM
NoQ updated this revision to Diff 76731.Nov 2 2016, 10:14 AM
NoQ edited edge metadata.

Comment up on variants.

This revision was automatically updated to reflect the committed changes.