Changed also all ssize_t to Py_ssize_t

Hummm, there are still some places where there may be loss of data:

D:\a\cpython\cpython\Modules\_zoneinfo.c(1790,35): warning C4244: 'function': conversion from 'Py_ssize_t' to 'uint8_t', possible loss of data [D:\a\cpython\cpython\PCbuild\_zoneinfo.vcxproj]
D:\a\cpython\cpython\Modules\_zoneinfo.c(1790,41): warning C4244: 'function': conversion from 'Py_ssize_t' to 'uint8_t', possible loss of data [D:\a\cpython\cpython\PCbuild\_zoneinfo.vcxproj]
D:\a\cpython\cpython\Modules\_zoneinfo.c(1790,46): warning C4244: 'function': conversion from 'Py_ssize_t' to 'uint8_t', possible loss of data [D:\a\cpython\cpython\PCbuild\_zoneinfo.vcxproj]

but these require possible changes in CalendarRule values.... Why are these uint8_t?

I am really not a fan of this. These are blighted unsigned values, there is no reason to use signed data types for this.

Yeah, I can see that. How do you want to proceed? There is still some mismatch with the precision of some of these types. I lack context on many of these so maybe is better to scope this PR on the ssize_t -> Py_ssize_t and you could fix the others in a separate one?

@pablogsal Yeah, I'm comfortable with changing ssize_t -> Py_ssize_t. We can also change num_* to size_t rather than ssize_t.

We can look at the uint8_t stuff later, but I think those are logically uint8_t, so I'd rather use assertions and/or error handling to enforce that rather than mess with the types.

@pganssle Ok, if I not mistaken this PR should contain what you proposed. Could you please check if everything is ok with you?

@pablogsal So I created this equivalent PR on the backport, which in some ways addresses the "loss of precision" issues. I'm not sure, can we disable the error on the uint8_t? I believe it's basically a false alarm; the function that's called returns the result of subtracting two char values, so the maximum range should be [255,255]. The current error checking logic uses tmp < 0, so the result is guaranteed to fit into a uint8_t.

That said, we can change the error check to also raise with tmp >= 256, like I've done in the other PR, but that did not fix the compiler warning.

I'm not sure, can we disable the error on the uint8_t? I believe it's basically a false alarm; the function that's called returns the result of subtracting two char values, so the maximum range should be [255,255]. The current error checking logic uses tmp < 0, so the result is guaranteed to fit into a uint8_t.

That said, we can change the error check to also raise with tmp >= 256, like I've done in the other PR, but that did not fix the compiler warning.

I would prefer to discuss that in a different PR as potentially involves reorganising some of the code (although the most likely outcome is suppressing the error).

I would prefer to discuss that in a different PR as potentially involves reorganising some of the code (although the most likely outcome is suppressing the error).

OK, do you want to comment on the backport PR? I'm planning to fix both at once in the backport.

I believe this solves https://bugs.python.org/issue40686, correct?

I believe this solves https://bugs.python.org/issue40686, correct?

Yeah it should.

Btw I would like to have the same code for the fix as the backport so we can keep those in sync. I will update this PR shortly

@pganssle I have updated the PR with the latest changes in your backport

@pablogsal: Status check is done, and it's a success ✅ .

Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

GH-20467 is a backport of this pull request to the 3.9 branch.