set_at now take intptr_t for x, y instead of int, and guards 32-bit architectures

[oddbookworm]

Fixes #2961
@ankith26 figured out that it was an int overflow when multiplying surf->pitch by y

[bilhox]

I don't like how the problem is solved, we aren't clamping the line in the clip rect so we have to check if each pixel of the line one by one are outside the clip rect. IMO, the best way to solve this problem is to delimit with new coordinates which part of the line is going to be drawn.

[ankith26]

LGTM, thanks 🎉

[Starbuck5]

I think this could be simpler by using long long everywhere instead of a pointer type with a scary 32 bit path. Even on 32 bit, long long is 64 bit. Or you could be explicit and use int64_t?

The math being done is not really about pointers so its also strange to put it in a pointer type.

[Starbuck5]

Gave it a test and just bringing in x and y as long longs in the set_at function call worked. It brings the changes to draw.c from 41 lines to 2 lines (because now the function definition spills onto 2 lines).

[oddbookworm]

@Starbuck5 blame Ankith on those last two comments of yours. That's what I originally had

[ankith26]

My reasoning for using intptr_t is that it is guaranteed to be as big as the pointer type. What this fix is doing is very relevant to pointer sizes. On a 32 bit platform, using a long long/int64_t doesn't fix the issue because the underlying pointer size is still 32 bits. We are essentially doing algebra on stuff that translates to addresses, and for this the C standard recommends this type.