-Warray-bounds misses unsafe pointer arithmetic

[shuffle2]

I would expect the following to issue a warning:

void g(uint64_t a, uint64_t b) {
    printf("%lx %lx\n", a, b);
}

int main(int argc, char **argv) {
    uint8_t a;
    
    // one-past the end is valid (as long as not deref'd)
    g((uint64_t)&a, (uint64_t)(&a + 1));
    // >1 past end is invalid
    // XXX clang has -Warray-bounds, but it does not warn on the below.
    // clang's -Wunsafe-buffer-usage *does* warn on it, though.
    // -Wunsafe-buffer-usage doesn't seem usable in real world tho for C code. (lots of false positives).
    g((uint64_t)&a, (uint64_t)(&a + 2));
    
    return 0;
}

gcc detects this as I'd expect, clang does not: https://godbolt.org/z/WEYTzMGGb

It's unclear to me if -Wunsafe-buffer-usage is the expected solution here - this flag seems unhelpful for plain C code. https://clang.llvm.org/docs/SafeBuffers.html makes it sound like the flag is mainly for use in C++ code, to detect locations that should be converted to c++-specific code patterns.

[KipHamiltons]

Here's what happens in the current code:

1. The type of the BaseExpr is uint8_t * here, which is not a ConstantArrayType. That means that this is nullptr.
2. We end up in the codepath for IsUnboundedArray, because we "don't have the size of the array" to do the bounds check.
3. That means we never actually do the bounds check, simply checking that we aren't overflowing the size of the address space before exiting without finding any issues, down here.

In order to fix this problem, we'd need to get the size information down into this function, passed as a parameter or attached to an existing parameter, in order to bounds check it. That'd be the next step.

On a sidenote, I think that the warning that we should trigger is -Warray-bounds-pointer-arithmetic, which happens just a bit later in this function under different conditions.

[KipHamiltons]

Getting that info requires a lot more effort than I had hoped. I find this quite funny though:

This generates a warning

../test.c:21:32: warning: the pointer incremented by 2 refers past the end of the array (that has type 'uint8_t[1]' (aka 'unsigned char[1]')) [-Warray-bounds-pointer-arithmetic]
   21 |     g((uint64_t)&a, (uint64_t)(a + 2));
      |                                ^   ~

But this doesn't, because the operand is of type pointer instead of constant size array:
g((uint64_t)&a, (uint64_t)(&a[0] + 2));

[shuffle2]

I should mention I actually found this deficiency with code like:

struct { uint8_t buf[32]; } a;

https://godbolt.org/z/4ozG7qder

which might(?) change the type analysis llvm is doing. Hopefully a fix would fix both cases.