gh-121427: Fixed type errors triggered when compiling with MSYS2/UCRT64

[rruuaanng]

Actually, it only requires preprocessing the parameter passing. I hope it won't cause data type truncation.

cc @vstinner

• Issue: Compiling 3.13 in MSYS2/UCRT64 causes a type error for _PyTime_AsTime_t #121427

[serhiy-storchaka]

This is not the correct fix. From the error message "expected 'time_t *' {aka 'long long int *'} but argument is of type 'long int *'" it can be seen that tv->tv_sec has type long int which is different from long long int.

[rruuaanng]

Actually my initial thought was to start with struct timeval, but maybe that's not appropriate :(

Edit
(I actually think casting to the target type might be better than this.)

Edit2
Suddenly I remembered that struct timeval seems to be defined in the system header file.

[bedevere-app]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[rruuaanng]

Hmmm.... Maybe this problem cannot be solved fundamentally. Unless we start from the function signature. At least I think that casting might be the solution. The author gave a thumbs up as feedback :)

[serhiy-storchaka]

Of course, it can be solved. You should just understand what this code do and what goes wrong. Find a function similar to _PyTime_AsTime_t that converts to long int. If it does not exist, look if there are other functions that convert to other integer types and write a similar code.

[rruuaanng]

In fact, what I'm worried about is that although forced conversion can solve the problem, what if the number value is cut off. (Maybe not)

[serhiy-storchaka]

No, it does not solve the problem. It creates a possible security issue (buffer overflow).

[erlend-aasland]

@rruuaanng: please do not create PRs for half-baked solutions; try to understand the problem first, and only when you have a clear solution, propose a PR. Your pattern of opening PRs with half-baked solutions only result in wasting review resources, wasting CI resources, and polluting the PR list. I'm closing this.