Can you add a comment around here that explains why this query catches things that cpp/integer-multiplication-cast-to-long doesn't catch?

how do you view this text?

// Search for an explicit conversion of the result of multiplication in the situation of multiplying types of a smaller size than the result 
// or casting the result of multiplication of comparable types to signed ones.
// In these situations, it is necessary to use the conversion not of the result, but of the arguments.

That still doesn't explain (at least not to me) what the difference between this query and cpp/integer-multiplication-cast-to-long is. As far as I remember, the goal of cpp/integer-multiplication-cast-to-long is also to detect cases like:

int i1 = ...;
int i2 = ...;
long j = i * i;

where there's an implicit cast on the result of the multiplication, but where the cast should really be on the arguments.

Is the difference just that this query requires the cast to be explicit, while cpp/integer-multiplication-cast-to-long requires the cast to be implicit?

yes, the idea of the request is that the developer uses an explicit override, which would have happened anyway, therefore, this is either stylistically incorrect or overflow.

I see. Thanks for clearing that up. Could you extend the description you wrote here to say that this query finds cases similar to the ones found by cpp/integer-multiplication-cast-to-long, but requires the cast to be explicit?

We have a range analysis library that can rule out cases that obviously doesn't overflow. See how it's used here: https://github.com/github/codeql/blob/main/cpp/ql/src/Likely%20Bugs/Arithmetic/SignedOverflowCheck.ql#L30 (there's only a convertedExprMightOverflow predicate that checks for both overflow and underflow at the same time). Would that be useful to rule out false positives in some cases?

I am considering this idea.
in my experience of using Range there are too many surprises of uncertainty.

in the first part, I hope for a difference in the sizes of the types of arguments and results, in the second time, that the signed result is 1 bit less than the arguments.

I propose to return to this point if other cleaning options are exhausted?

in my experience of using Range there are too many surprises of uncertainty.

I'd be interested in hearing what you mean by this.

I propose to return to this point if other cleaning options are exhausted?

That's fine.