This warning tries to catch programs that incorrectly call memset with the second and third arguments transposed, ie memset(ary, sizeof(ary), 0) instead of memset(ary, 0, sizeof(ary)). This is done by looking at two factors: 1) if the last argument is 0, then this is likely a bug (looks this is what GCC's implementation does) and 2) if the last argument isn't 0, but the second argument is a sizeofexpression. This catches cases like memset(ary, sizeof(ary), 0xff). I also grouped a couple of related diagnostics that deal with these c functions into a new group, -Wsuspicious-memaccess.

I chose int because that's the actual type of the second parameter to memset, it just gets casted down to unsigned char internally. FWIW, either type will suppress the warning. I'm fine with recommending unsigned char if you have a strong preference for it.

Personally I have a strong preference for "any 8-bit type" — the important thing is that it needs to indicate to the reader that it's intended to be the single-byte value that memset expects. I even want my compiler to diagnose memset(x, 0x1234, z) as a bug!
But I'm not inclined to fight hard, because this is all about the mechanism of *suppressing* of the warning, and I don't imagine we'll see too many people trying to suppress it.

lgtm assuming you ran this on some large code base to make sure it doesn't have false positives.

Sorry for the delay here, I was running this on some very large internal code bases. This is overwhelmingly true-positive, but there are 2 improvements I want to make here before landing this:

Suppress the diagnostic in cases like memset(ptr, 0xff, PADDING), when PADDING is a macro defined to be 0.

Some platforms #define bzero to __builtin_memset, so we should recognize when we're in a macro expansion to bzero and emit a more accurate diagnostic for bzero(ary, 0);. We might as well add support for __builtin_bzero too.

Looks like clang doesn't have a builtin for wmemset, its just defined as a normal function. I suppose that we could still try to diagnose calls to top-level functions named wmemset, but thats unprecedented and doesn't really seem worth the trouble.

You should add a test case proving that memset(x, 0, 0) doesn't get diagnosed (assuming the two 0s come from two different macro expansions, for example).
My sketch above would fail to diagnose memset(x, 0, 255). I don't know if this is a feature or a bug. :) You probably ought to have a test case for that, either way, just to demonstrate the expected behavior.

I definitely don't think that ThirdArg being 255 should lead to a diagnostic, regardless of what SecondArg is. I'm fine with omitting a diagnostic in memset(ptr, 255, 0), but if the user explicitly spelled out 0 then I would probably prefer to diagnose. FWIW, for the case I found where we emitted a false-positive the second argument was 0xd9 or something.