I think the exprMightOverFlow predicates become a bit too noisy when we include all unanalyzable expressions. Consider this example from https://github.com/github/codeql/blob/main/cpp/ql/test/query-tests/Security/CWE/CWE-190/semmle/tainted/test2.cpp:

typedef struct _myStruct {
	s64 val;
} MyStruct;

void test2_sink(s64 v, MyStruct s, MyStruct &s_r, MyStruct *s_p)
{
	s64 v1 = v * 2; // bad
	s64 v2 = s.val * 2; // bad
	s64 v3 = s_r.val * 2; // bad
	s64 v4 = s_p->val * 2; // bad
}

We now flag all of the field accesses in this function as possibly overflowing, which doesn't make a lot of sense.

Surprisingly there's only one change in CPP differences - a heavily templated comparison in Boost that we lose, that looks like it was indeed a false positive (though I'm not sure the exact mechanics of it being ruled out by this change).

Yeah, I agree that the CPP-differences change looks good (the query should probably filter out templates anyway). I don't like why it's being ruled out, though. We rule it out because we now consider both of these operations as potentially overflowing:

bool CondV = (thread_access_mode_of< LeftLockT >::value < thread_access_mode_of< RightLockT >::value)

but really they're just constant values that will be deduced in every template instantiation.

I'm also not sure I like the changes in our tests.

One thing we could do is to only say that unanalyzable Operations are potentially overflowing/underflowing. Although this is starting to feel less principled.

Should there be two versions of the predicates then? It seems legitimate to only want cases where we're least / most confident an overflow can occur (even if accuracy is not guaranteed either way), but on the other hand this will clutter up the interface to this library and give users more opportunity to make the wrong choice.

Should there be two versions of the predicates then? It seems legitimate to only want cases where we're least / most confident an overflow can occur (even if accuracy is not guaranteed either way), but on the other hand this will clutter up the interface to this library and give users more opportunity to make the wrong choice.

Yeah, there seem to be situations where we want the old semantics and other situations that call for the new semantics of those predicates. I was hoping that we didn't have to add a whole new predicate to the public interface, though :( This seems to be a discussion that would be helpful to have for the future IR-based range analysis as well, so maybe we should bring the discussion to a team meeting (as a very low priority topic).

Note to self if we end up merging a version of this: Use this PR to make bb447d7 more aesthetically pleasing.

New CPP-difference: https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/1938/

New CPP-difference: https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/1938/

CPP-differences looks good. There is one query result change, and it's in a query that doesn't actually use range analysis so it looks like wobble.

There was a single test change. This is fixed by 86822f6 following a Slack discussion here.

Why is no change note required? The range analysis library has external users, and they might be affected by this new behaviour.

Why is no change note required? The range analysis library has external users, and they might be affected by this new behaviour.

Good point. We should have a change note for this.

LGTM. I'll leave the merging to @geoffw0 when he's satisfied.

Note to self if we end up merging a version of this: Use this PR to make bb447d7 more aesthetically pleasing.

^ reminder.

Note to self if we end up merging a version of this: Use this PR to make bb447d7 more aesthetically pleasing.

^ reminder.

Thanks for the reminder. That fix is now up: #5780