C type `long` is 4-byte integer in 64-bit Windows build (MSVC behavior). [1]
In other compilers, `long` is 8-byte integer in 64-bit build.

This leads to a bit unnecessary performance waste, issue38252 fixed this problem in a situation.

Search `SIZEOF_LONG` in CPython code, there's still a few long type waste.

Novices are welcome to try contribution.

[1] https://stackoverflow.com/questions/384502

What is the problem exactly?

> What is the problem exactly?

There are several different problems, such as:
https://github.com/python/cpython/blob/v3.10.0a2/Modules/mathmodule.c#L2033

In addition, `utf16_decode` also has this problem, I forgot this:
https://github.com/python/cpython/blob/v3.10.0a2/Objects/stringlib/codecs.h#L465

Maybe these small problems are suitable for newcomer to familiarize the contribution process.

I do not think that this is suitable for newcomers because you need to have deep understanding why it was written in such form at first place and what will be changed if you change it.

The code was written when unsigned long long was not standard and 64-bit integer type was not required in Python. PyLong_FromUnsignedLongLong could just not exist on the particular platform. Using long long optionally would complicate the code, and it was not always justified. And it could negatively affect performance, especially on 32-bit platforms.

> There are several different problems, such as:
> https://github.com/python/cpython/blob/v3.10.0a2/Modules/mathmodule.c#L2033

I don't think that it's worth it to optimize this one.

> In addition, `utf16_decode` also has this problem, I forgot this:
https://github.com/python/cpython/blob/v3.10.0a2/Objects/stringlib/codecs.h#L465

I suggest to fix in it bpo-38252.

> I do not think that this is suitable for newcomers because you need to have deep understanding why it was written in such form at first place and what will be changed if you change it.

I agree contributors need to understand code, rather than simply replace the type. Maybe two weeks is enough to understand the code.

> And it could negatively affect performance, especially on 32-bit platforms.

`long` type can be replaced by `ssize_t`.
`unsigned long` type can be replaced by `size_t`.
And use `PyLong_FromSize_t`/`PyLong_FromSize_t`, then there is no negative impact.

> I don't think that it's worth it to optimize this one.

Although the speedup is small, it's free.
I don't see it as optimization, just no more waste.

> I suggest to fix in it bpo-38252.

I forgot it in that issue, I just searched "0x80808080" in the code, it was missed.