r369217 - [Diagnostics] Diagnose misused xor as pow

[Arthur O'Dwyer via cfe-commits]

On Mon, Aug 19, 2019 at 1:53 PM Nico Weber via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> Hi,
>
> this results in a false positive on webrtc, on this code:
>
>
> https://cs.chromium.org/chromium/src/third_party/libwebp/src/enc/picture_csp_enc.c?q=picture_csp_enc.c&sq=package:chromium&dr&l=1002
>
> The code does this:
>
> #ifdef WORDS_BIGENDIAN
> #define ALPHA_OFFSET 0   // uint32_t 0xff000000 is 0xff,00,00,00 in memory
> #else
> #define ALPHA_OFFSET 3   // uint32_t 0xff000000 is 0x00,00,00,ff in memory
> #endif
>
> // ...
>
>     const uint8_t* const argb = (const uint8_t*)picture->argb;
>     const uint8_t* const a = argb + (0 ^ ALPHA_OFFSET);
>     const uint8_t* const r = argb + (1 ^ ALPHA_OFFSET);
>     const uint8_t* const g = argb + (2 ^ ALPHA_OFFSET);
>     const uint8_t* const b = argb + (3 ^ ALPHA_OFFSET);
>
> The idea is to get bytes 0, 1, 2, 3 as a, r, g, b if ALPHA_OFFSET is 0, or
> bytes 3, 2, 1, 0 if ALPHA_OFFSET is 3.
>
> Maybe this shouldn't fire if the rhs is a macro?
>

Does it show a fix-it that suggests replacing
    #define ALPHA_OFFSET 3
with
    #define ALPHA_OFFSET 0x3
? That would be the quickest way to shut up the warning, if I understand
correctly. The use of hexadecimal or octal or binary indicates
unambiguously that you mean to do a bitwise operation (xor), not an
arithmetic one (pow).

If the use of a macro here *prevents* the hex workaround from working, then
I'd call that a bug in the diagnostic.

It would be great if Clang could do what humans do instinctively, and see
that this "2 ^ FOO" is actually part of a larger pattern — "0 ^ FOO, 1 ^
FOO, 2 ^ FOO, 3 ^ FOO" — and therefore it probably isn't wrong unless the
three surrounding lines are also wrong. However, I'm pretty sure that Clang
isn't set up to discover "patterns" like this in general.  It sees "2 ^
LITERAL_EXPONENT" and gives a warning regardless of the surrounding lines.

–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20190819/99e52b0d/attachment.html>