[PATCH] D79430: [analyzer] StdLibraryFunctionsChecker: Add LazyRanges to support type dependent Max

Gabor Marton via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed May 6 08:02:59 PDT 2020


martong added a comment.

In D79430#2022222 <https://reviews.llvm.org/D79430#2022222>, @xazax.hun wrote:

> I am a bit unsure what the purpose of these `Max` summaries are? As far as I understand the `Max` represents the largest value for the type of the formal parameter.


Yes, that's right. The tricky part here is that, when we write the summary we may not know what is going to be the type. In some cases (e.g. `read` with `ssize_t`) it turns out only after we looked up the `FunctionDecl`.

> Isn't it always an error to pass a value that is larger than the formal's type can represent?
>  If the answer is yes, I think we should have a separate checker for catching those overflows. If the answer is no, we might want to express a simpler summary, something like `cannot overflow on argument X`.

The answer is yes. And yep we could have such a checker. But please read on.

> Do we really ever need to specify this in a summary?

It would be possible to have a different DSL for describing the summaries. Now, the `RangeConstraint` requires a list of ranges, but that's just some technical detail. So, instead of

  .ArgConstraint(ArgumentCondition(0, WithinRange, Range(0, Max)))

we could have

  .ArgConstraint(ArgumentCondition(0, WithinRange, GreaterThanOrEqTo(0)))

. In this case, however, `GreaterThanOrEqTo` would return a range(0, Max). And `Max` still would be something that we can evaluate only lazily (once we have the FunctionDecl).
I prefer the explicit Range(0, Max) notion, because then the range is seen immediately.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79430





More information about the cfe-commits mailing list