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

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

Hi jordan_rose,

This duplication was motivated by the following:
- FIXME from unix.API stating "Eventually these should be rolled into the MallocChecker, but right now they're more basic and valuable for widespread use."
- an idea to extend the check to handle zero size allocation by 'new' and 'new[]' in the sequel.
- create the base for implementation of undefbehavior.ZeroAllocDereference checker.

The patch is a scratch, may it make sense to make '0 size allocation' the separate checker to at least preserve handling of zero-size realloc unchanged.

I suggest the following logic for handling zero-size realloc:
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.
Specification C11 n1570, 7.22.3.1 says: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
Usage of the returned pointer is planned to be a matter of other checkers (undefbehavior.ZeroAllocDereference + maybe another checker that checks for usage of returned pointer in comparisons)

Please review!

http://reviews.llvm.org/D6178

Files:
  lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  test/Analysis/malloc-annotations.c
  test/Analysis/malloc.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D6178.15940.patch
Type: text/x-patch
Size: 27884 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141108/9b47d9ac/attachment.bin>