[analyzer] core.UndefinedBinaryOperatorResult false positive on C arrays cast

[hedrok]

#include <stdio.h>

int main()
{
    unsigned int ints[2] = {0xaabbccdd, 0xff};
    unsigned char* bytes = (unsigned char*)ints;
    printf("0x%x\n", bytes[1] | 1);
}

Calling

scan-build clang false-positive.c

Gives

scan-build: Using '/usr/lib/llvm-22/bin/clang' for static analysis
false-positive.c:7:31: warning: The left operand of '|' is a garbage value [core.UndefinedBinaryOperatorResult]
    7 |     printf("0x%x\n", bytes[1] | 1);
      |                      ~~~~~~~~ ^
1 warning generated.
scan-build: Analysis run complete.
scan-build: 1 bug found.
scan-build: Run 'scan-view /tmp/scan-build-2025-11-18-191927-81-1' to examine bug reports.

Checked for versions:

Debian clang version 22.0.0 (++20251015112211+4ad625b15bc1-1~exp1~20251015112229.1767)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-22/bin

And

Debian clang version 19.1.7 (++20250114103228+cd708029e0b2-1~exp1~20250114103334.78)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: Kyrylo Yatsenko (hedrok)

```c #include <stdio.h>

int main()
{
unsigned int ints[2] = {0xaabbccdd, 0xff};
unsigned char* bytes = (unsigned char*)ints;
printf("0x%x\n", bytes[1] | 1);
}

Calling
```bash
scan-build clang false-positive.c

Gives

scan-build: Using '/usr/lib/llvm-22/bin/clang' for static analysis
false-positive.c:7:31: warning: The left operand of '|' is a garbage value [core.UndefinedBinaryOperatorResult]
    7 |     printf("0x%x\n", bytes[1] | 1);
      |                      ~~~~~~~~ ^
1 warning generated.
scan-build: Analysis run complete.
scan-build: 1 bug found.
scan-build: Run 'scan-view /tmp/scan-build-2025-11-18-191927-81-1' to examine bug reports.

Checked for versions:

Debian clang version 22.0.0 (++20251015112211+4ad625b15bc1-1~exp1~20251015112229.1767)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-22/bin

And

Debian clang version 19.1.7 (++20250114103228+cd708029e0b2-1~exp1~20250114103334.78)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-19/bin

[steakhal]

Here is a Compiler Explorer link: https://godbolt.org/z/Wzd8Tv6s5

I think this relates to the Store when we resolve the load from &Element{ints,1 S64b,unsigned char}; we somehow fail to see through the cluster of ints:

    { "cluster": "ints", "pointer": "0x47350490", "items": [
      { "kind": "Direct", "offset": 0, "value": "2864434397 U32b" },
      { "kind": "Direct", "offset": 32, "value": "255 U32b" }
    ]},

We should have seen that &Element{ints,1 S64b,unsigned char} desugars into bit offset 8, thus reads part of the first binding (2864434397 U32b).

I'm actually surprised that this doesn't work because it's not too complicated.
I figured we already handle this case. It shouldn't be too difficult to see where it goes wrong, just set a breakpoint to RegionStoreManager::getBinding(RegionBindingsConstRef B, Loc L, QualType T) and follow where it goes and returns.

[NagyDonat]

My first impression is that this is a true positive: the standard does not define the memory representation (endianness or even the number of bytes) of an int, so I think it is undefined behavior to cast an int to a character array and read particular elements. Even in practice, the example code would produce different results depending on the endianness of the system.

[steakhal]

I don't think it's UB. Observing an object as chars should be okay. Writing through is debatable, but anyway, this should work in CSA.
And even if writing would be an issue, reading undefined value is simply not true. This is clearly a bug in the engine.

[NagyDonat]

🤔 Fair point, the character value is not undefined (=garbage), but only implementation-defined.

I agree that this shouldn't be reported by the core.UndefinedBinaryOperatorResult checker and analogous checkers, but if ideally there should be a checker (probably a new one, e.g. optin.EndiannesDependentValues) which reports code like this.

My first instinct is that in this "read a byte from the middle of a number" situation (where the analyzer currently returns Undefined) the result should be either a SymbolConjured or a new kind of symbol that represents "$n$th byte of this number". (We cannot return a concrete number because it depends on endianness.)

[hedrok]

In my specific case it is known that the ints contain data in network byte order. There are functions that encode data to such ints and functions that decode data from such ints, and others that manipulate them as bytes after such conversion in similar way to what I've reported, knowing that they contain data in network byte order. (I'm just a contributor in that project, I'm not ready to protect this design decision, but it works and it doesn't depend on system endiannes)

Also maybe you can do that, but I think it would be extremely hard to take into account ifdefs` like

#if __BYTE_ORDER == __LITTLE_ENDIAN
...
#endif

or any other check from https://stackoverflow.com/questions/4181951/how-to-check-whether-a-system-is-big-endian-or-little-endian if you decide to add EndiannesDependentValue checker.