While analyzing code
memcmp(a, NULL, n);
where a has an unconstrained symbolic value, the analyzer is currently emitting a warning about the first argument being a null pointer, even though we'd rather have it warn about the second argument.
This happens because CStringChecker first checks that the two argument buffers are in fact the same buffer, in order to take the fast path. This boils down to assuming a == NULL to true. Then the subsequent check for null pointer argument "discovers" that a is null.
This could have been fixed by reordering the checks (first check null arguments, then check for overlap) but i went a bit further and entirely removed the state split for "same buffer vs. different buffers". This state split is not well-justified: we cannot deduce from the presence of memcpy in the code that the buffers may in fact overlap. Instead, i conservatively assume that they don't overlap, unless they're already known to certainly overlap on the current execution path. This loses a bit of coverage but the lost path is where they do actually overlap. This path is in my opinion not only rare but also fairly useless, as it immediately introduces an aliasing problem that we aren't quite ready to deal with.