[cfe-commits] Patch: Warn on zero-length memaccess
Jordan Rose
jordan_rose at apple.com
Thu Jun 14 10:16:24 PDT 2012
Hi, Chris. test/Analysis is really for static analyzer tests, not for compile-time analysis tests (even those that use libAnalysis). bstring.c and string.c are run multiple times to test the analyzer for when the builtin versions are and aren't available. Finally clang_analyzer_eval is used to test the static analyzer's understanding of an expression; it will print TRUE or FALSE if it can find a path where it can prove the value is non-zero/zero and UNKNOWN otherwise.
The upshot of all of this is that your new tests should go in Sema, for compile-time semantic warnings.
I think Chandler's right that this really only applies to memset; anything else will already warn on the sizeof not being castable to a pointer. And these zero-length memcpy calls will be optimized out by LLVM anyway, so Clang shouldn't need to worry about checking these prematurely.
The right way to suppress this isn't using void*. I think Chandler's point about ignoring macros and template parameters will cover most of the important cases; the diagnostic macros will cover the few other rare cases.
Thanks for coming up with this!
Jordan
On Jun 13, 2012, at 10:21 AM, Chris Pickel wrote:
> Hi, cfe-commits,
>
> After spending far too long tracking down a bug which was ultimately
> caused by the line:
>
> memset(&x, sizeof(x), 0); // Should be memset(&x, 0, sizeof(x))
>
> I wrote a clang patch which adds a diagnostic for this situation. It
> warns on any call to a memaccess function (memset, memcpy, memcmp,
> &c.) in which a literal "0" is passed as the size. Like other
> memaccess diagnostics, it can be suppressed by casting &x to void*.
>
> The git-formatted patch is attached, but it fails a few tests, and I'm
> not sure what the correct fix is. The test log is attached too; a
> summary is:
>
> Analysis/bstring.c:
> "TRUE" warnings expected in addition to zero-length memaccess warnings
>
> Analysis/string.c
> Warns on __builtin_strncpy instead of strcpy
> But if I change the expectation, then it warns on strcpy instead
>
> SemaCXX/warn-zero-length-memaccess:
> SemaCXX/zero-length-arrays:
> Implicit copy-constructors appear to generate calls to
> __builtin_memcpy(…, 0)
> This warning shouldn't really be checking __builtin_memcpy()
> On the other hand, should __builtin_memcpy(…, 0) be generated to begin with?
> <llvm-test.txt><0001-Warn-on-zero-length-memaccess.patch>_______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
More information about the cfe-commits
mailing list