Fix some overflows in drawing.#22153
Conversation
alalek
left a comment
There was a problem hiding this comment.
May be we should add some checks for input to avoid overflows instead?
Changing int -> int64 computations may affect performance on some platforms.
|
in my opinion, the patch is perfectly fine. drawing functions in OpenCV are not speed champions, they could be done more efficient, of course, but the proposed change should not affect speed. It's just a few more clocks spent in coordinates handling. As for checks for the input - the problem is that the use case may be real. If we use 16 bits for fractional part and if the image is huge satellite image with more than 32K pixels in width/height, it can indeed overflow 32 bits. This is where 64-bit arithmetics may come handy. |
|
Please take a look on build warnings from MSVS compiler: https://pullrequest.opencv.org/buildbot/builders/3_4-win64-vc14/builds/100002
|
| edge[0].dx = edge[1].dx = 0; | ||
|
|
||
| ptr += img.step*y; | ||
| ptr += (int64_t)img.step*y; |
There was a problem hiding this comment.
int64_t is C++11 stuff and it is not available on 3.4 branch.
3.4 branch must use cv::int64 instead.
Those were found through fuzzing.
I see there is some pessimization too: circle could have a for loop over the image in case the circle is not fully inside (instead of over the circle as done now).
Pull Request Readiness Checklist