This is very hard for me to follow, and probably one of the core reasons I still have difficulty wrapping my head around this query.

First, LHS and RHS are pretty generic terms and on first reading I though that LHS meant the result of the PAI, which is clearly incorrect. It seems that you're talking about the 1st and 2nd (left and right) operand of the PAI and not the result.

Second, "non-strictly upper bounds" takes me a few seconds to understand every time I read it. I would be helped if we could just express this as a formula with a <= in it. Also, I think it would help if some intuition was provided here. Why are with interested in a non-strict upper bound? Most values in the range that this upper bound provides are non-problematic, because they fall within the allocated array, but apparently this doesn't hold for all of them?

First, LHS and RHS are pretty generic terms and on first reading I though that LHS meant the result of the PAI, which is clearly incorrect. It seems that you're talking about the 1st and 2nd (left and right) operand of the PAI and not the result.

Ah, I see your confusion. My reason for calling them left-hand side and right-hand side was because that's the names of the predicates on the PAI class. i.e., for an instruction

r3(glval<char>)     = PointerAdd[1]            : r1, r2

I call r1 the left-hand side and r2 the right-hand side because that's corresponds to calling getLeftOperand() and getRightOperand() on the PointerArithmeticInstruction class.

Would it be more clear if I write something like:

* This is done using the product-flow library. The configuration tracks flow from the
* pair `(allocation, size of allocation)` to a pair `(a, b)` where there exists a
* pointer-arithmetic instruction `pai = a + r` such that `b` is a dataflow node that
* represents an operand that _non-strictly_ upper bounds `r`. See
* `pointerAddInstructionHasBounds` for the implementation of this.

? (note that the above text hasn't yet accounted for your second comment about non-strictly upper bounds).

I would have been fine with just left and right operand, but this works too (somewhat better even).

Also the pointer represented by a will always be equal to the result of the allocation, right? This is something that should probably also be mentioned.

Second, "non-strictly upper bounds" takes me a few seconds to understand every time I read it. I would be helped if we could just express this as a formula with a <= in it.

I can definitely rewrite it to use a formula instead, sure.

Also, I think it would help if some intuition was provided here. Why are with interested in a non-strict upper bound? Most values in the range that this upper bound provides are non-problematic, because they fall within the allocated array, but apparently this doesn't hold for all of them?

I can describe that a bit more clearly, sure. To wrap your head around why we're interested in a non-strict upper bound it's useful to think of an example like:

char* p = new char[size];
char* end = p + size;
char* q = somehow_get_pointer(p);
if(q <= end) {
  *q = '\0' // BUG: This may be equal to `end`
}

and the we're looking for a pointer that's non-strictly upper bound by the end-pointer (in a formula: a pointer ptr such that ptr <= end) because this means that there's some guard condition that is "too loose" (i.e., like in the above where <= should have been <). This is what we can learn by using the new range analysis: semBounded(a, b, delta, true, g) and delta >= 0 tells us that a <= b + delta because of the guard g. If it holds that semBounded(a, b, -1, true, g) this would mean that a <= b - 1 (i.e., a < b) because of g - and in this case the pointer would be properly guarded.

This is what I tried to communicate in the top of the query file:

The goal of this query is to identify issues such as:
```cpp
1. int* base = new int[size];
2. int* end = base + size;
3. for(int* p = base; p <= end; ++p) {
4.   *p = 0; // BUG: Should have been bounded by `p < end`.
5. }
```cpp

but maybe that wasn't as clear as I would've hoped.

Would an explanation such as the above help with wrapping your head around the query?

Also the pointer represented by a will always be equal to the result of the allocation, right? This is something that should probably also be mentioned.

Yep. I'll make sure to mention this as well 👍

Note that I was trying to be somewhat provocative with regard to asking for an intuition. I think the critical part I always have to think about is that if I do anything with the base + size pointer, then I need to be very careful, as that points to something that is "just a bit" out-of-bounds due to having a non-strict bound here.

5270cf6 fixes the first part.

Related: #13789 updates the QLDoc in the query predicates to use <= instead of writing out [...] is upper-bounded by [...].