[PATCH] [Review request][analyzer] Duplicate '0 size allocation' check from unix.API in unix.Malloc.

[Антон Ярцев]

"Have you added a test to make sure that is the case? (If yes, what's the function name. I could not easily find it.) It would be similar to the path-sensitive check you've added but the check against '0' would be done in an inlined function."
Done, 'void testMallocIdc(int i)' added.

"Looks like you've removed the checks from the unix checker along with the tests. Can you add the tests back? I suggest adding your checker to the test file that contains the existing tests and check that it produces the same exact output."
Done.

"char *foo = realloc(ptr, 0); // TODO:expected-warning{{Call to 'realloc()' has an allocation size of 0 bytes}}
Why should we warn in this case? It is possible that someone is trying to free the memory by calling "realloc(ptr, 0)"
It is unsafe to use the value returned from an allocation function that was asked for a zero-allocation ( C11 n1570, 7.22.3.1 ).
I changed the checkers behavior to those we've discussed above:

1. if the returned value of realloc(p, 0) is not assigned then silently treat it as simple 'free' (the old behavior of unix.Malloc)
2. if the returned value is assigned then fire '0 size allocation' warning as the usage of the returned pointer is not safe.

Additional changes in the new patch:

- renamed 'BasicAllocationCheck' to 'ZeroAllocationCheck' (MallocChecker.cpp)
- cut old zero-allocation tests that depended on the memory returned from zero-realloc:
- reallocSizeZero1(), reallocSizeZero2() - tested specific case when we try to free memory that was already freed by zero-realloc, in the case when reallocation failed.
- reallocSizeZero3, reallocSizeZero4, reallocSizeZero5 - tested that we don't track memory returned from zero-allocated realloc().

If the patch gets in as is all this tests will produce 'zero-size allocation warning' at the point 'char *r = realloc(p, 0);'
There is no need to modify an old code that handles 'realloc', all the code is still in use. Nothing special is done to stop tracking memory returned from zero-realloc, in case of zero-realloc we just return from the function that handles 'realloc' (MallocChecker::ReallocMem()) before the code that allocates memory and processes the return value.


http://reviews.llvm.org/D6178

Files:
  lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  lib/StaticAnalyzer/Checkers/UnixAPIChecker.cpp
  test/Analysis/malloc-annotations.c
  test/Analysis/malloc.c
  test/Analysis/unix-fns.c

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D6178.17662.patch
Type: text/x-patch
Size: 48734 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141229/fd054872/attachment.bin>