---
id: limitations
title: Limitations, etc
---

## Expectations <a name="expectations"></a>

We want to be clear that if you run Infer on your project you might get very
good results, but it is also possible that you don't. Although we have had good
fix rates working with Facebook mobile codebases, we are not making strong
claims about rates of false alarms or similar when applied to arbitrary
codebases. For example, we have had some success
[getting bugs fixed in the DuckDuckGo Android App](blog/2015/05/22/Infer-on-open-source-android-apps),
but we encountered many false alarms when running Infer on GNU coreutils. It is
typical of program verification and static analysis tools that their results
vary, and that is to be expected, e.g., because they are tackling undecidable
problems and because different codebases they are applied to will have been
coded differently.

The good thing, though, is that you might get useful results! And, where the
results are imperfect, this can be taken as input for improvement.

Apart from these general remarks, Infer has a number of specific technical
limitations, which we describe in terms of bug types and language features.

## Bug types <a name="bugtypes"></a>

At present Infer is reporting on a restricted collection of
[bug types](/docs/checkers-bug-types), typically involving null pointers
and memory or resource leaks. The initial set of bug types Infer has focused on
was driven by the most pressing needs for serving the Facebook mobile
developers. Our approach has been to report less initially, to iterate with
developers and provide value to them, and gradually expand what we can do while
still providing value.

Some bug types we don't report as of yet include

- Array bounds errors
- Cast exceptions
- Leaking of tainted data
- Concurrency race conditions

and more. In the first three cases we have partial treatments inside of Infer,
but we have not surfaced these capabilities yet; the reports are not of
sufficient quality to present to developers. For example, Infer can find some
potential array bounds errors, but many of its reports are false alarms and it
misses still more.

Put another way: there is more work to do!

## Language Features <a name="languagefeatures"></a>

A different dimension in which Infer is limited concerns language features.
Infer either does not understand or has a weak treatment of

- Concurrency, including Java's Concurrency Utilities and iOS's Grand Central
  Dispatch
- Dynamic dispatch
- Reflection
- Android lifecycles
- Arithmetic
- and more

Some of these problems are fundamental, largely open, problems in program
analysis (especially concurrency), while for others there is much prior and
successful work to draw upon (e.g., arithmetic) and are simply on our todo list
awaiting work.

Thus, Infer's core algorithms can be understood as being sound with respect to
an idealized model (that is all soundness can ever be), but this idealized model
is some distance from real execution models for programs where Infer is
deployed. One consequence of this is that we cannot claim that Infer reasons
about <i> all </i> flows through an application, but only <i> some </i> flows.

In approaching these limitations going forward we must consider solutions that
take into account our use case: to comment in minutes on modifications to large
codebases. Methods based on whole program analysis are challenging to consider
when approaching these problems for our deployment model.

These limitations can be seen positively as opportunities for improvement, to do
more static analysis and program verification for the benefit of programmers
everywhere! We will be delighted if people from the static analysis and program
verification communities join us in working on these problems.