[cfe-commits] Patch: Warn on zero-length memaccess

[Chandler Carruth]

On Wed, Jun 13, 2012 at 10:21 AM, Chris Pickel <sfiera at sfzmail.com> 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))
>

FWIW, I think this makes more sense w/ memset than any others -- 0 isn't
valid for either the source or destination of memcpy / memcmp / memmove.

Also, I would want to make sure that the '0' is not actually computed from
a macro or template parameter.


>
> 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?
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120613/c7e3b8e8/attachment.html>