LGTM.com - false positive Multiplication result may overflow 'int' before it is converted to 'size_t'.

[sandsmark]

It doesn't seem to understand bounds checking before conversion, or that the value returns with the thrown exception I guess:
https://lgtm.com/projects/g/sandsmark/genieutils/snapshot/83dc9ec17bc36ac8f77bbbf82fae9ffbbd6ceeca/files/src/resource/SmxFrame.cpp?sort=name&dir=ASC&mode=heatmap#L145

y is checked right before, m_normalHeader.width is checked before the loop (line 116).

[sandsmark]

y is checked at the end of the loop as well (line 179), but I tested checking the size of the vectors it is compared to before the loop and it didn't help (though it would be the best, would be one less conditional in a semi-hot path even if the rest of the code there thrashes stuff).

[intrigus-lgtm]

The C standard only guarantees that an int can take values in the range [-32767,+32767].
Therefore the multiplication could indeed overflow on an exotic platform.

[sandsmark]

true, and I expect getting a static analyzer to remember something like static_assert(std::numeric_limits<int>::max() >= 2147483647ull && "We assume a sane int size in bounds checking"); or something is a bit unrealistic.

[jbj]

Thanks for the report. I think the main problem for the range analysis is that m_normalHeader.width is not tracked as a value because it's a field of an object. Only local variables are tracked, so the guard is simply invisible to the analysis.

We have most of the building blocks we'd need for fixing this, but realistically it's not on the roadmap to put them together in this particular way. I'll keep this bug open in case we get reports of similar issues and want to group them.