scan-build memory leak false positive

[llvmbot]

Bugzilla Link	16113
Version	3.2
OS	Linux
Attachments	scan-build annotated source file.
Reporter	LLVM Bugzilla Contributor
CC	@belkadan

Extended Description

Consider the following C program (key locations marked by comments):

include

include

size_t do_stuff(void **out, unsigned m) { size_t n;

if (m >= SIZE_MAX/4) /* (A) */
    return -1;
n = (size_t)m * 4; /* (X) */

*out = malloc(n); /* (B) */
if (!*out) /* (C) */
    return -1;

return n; /* (Y) */

}

int main(int argc, char *argv) { void buf; size_t n;

n = do_stuff(&buf, argc);
if (n == (size_t)-1) /* (D) */
    return EXIT_FAILURE; /* (E) */

free(buf);
return EXIT_SUCCESS;

}

The report produced by scan-build suggests that a memory leak is possible by the following path:

1: false branch at (A) 2: allocate memory at (B) 3: false branch at (C) 4: true branch at (D) 5: memory not freed at (E)

But this is clearly a false positive: taking the false branch at (A) means that m is less than SIZE_MAX/4, so the result of the multiplication at (X) must be less than 4(SIZE_MAX/4). Thus, n must be less than 4(SIZE_MAX/4), which implies that n must be less than SIZE_MAX. (size_t)-1 is equal to the maximum representable value of size_t as per C's rules of signed-to-unsigned conversions, i.e., (size_t)-1 is equal to SIZE_MAX. Hence, we can conclude that n is not ever equal to (size_t)-1 at / (Y) /.

The first 3 steps of this path imply that we got to the return at (Y) in do_stuff, which we have established returns a value not equal to (size_t)-1. It is therefore impossible to take the true branch at (D) and thus the conclusion of the analyzer is incorrect.

[belkadan]

Unfortunately, we don't currently model "m * 4", only additive constraints. To work around this, you can add "assert(n < SIZE_MAX);" after line (X).

[llvmbot]

assigned to @tkremenek