gh-98248: Normalizing the error messages in function struct.pack

[yanjs]

Provide informative error messages in function struct.pack when its integral arguments are not in range.

• Issue: struct.pack error messages are misleading and inconsistent #98248

[bedevere-bot]

Most changes to Python require a NEWS entry.

Please add it using the blurb_it web app or the blurb command-line tool.

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[yanjs]

Reference to a related PR: #28178

[yanjs]

Completed. Any comments or suggestions would be greatly appreciated.

[yanjs]

Should I change the definition of macro RANGE_ERROR and function _range_error in Modules/_struct.c? Some arguments of RANGE_ERROR are not used. _range_error cannot handle long long and unsigned long long. I didn't change them since they are used by some other correct functions.

[yanjs]

Thank you for your reviews, @kumaraditya303 @mdickinson. I have one more question. Should I remove parameters x and mask from macro RANGE_ERROR in the previous commit 61c016b Modules/_struct.c line 278?

Reasons not to make this change:

1. Some other working lines of code are modified.
2. In future, more detailed error messages can use the x.

Reasons to make this change:

1. x and mask are not used in the macro body.
2. In 61c016b, Modules/_struct.c line 672, x may be undefined, which is not good. It will not cause problems in runtime since this x will be erased by the macro.

I will make this change in the next commit 856a9be. If you feel this change is unnecessary, you can revert this commit.
I think the error in the automatic check is not related.

[mdickinson]

Thanks for the updates. It might be a few days before I have time to re-review; feel free to ping if you don't hear anything by mid-November.

Should I remove parameters x and mask from macro RANGE_ERROR

Sounds fine to me in principle.

[bedevere-bot]

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.

[yanjs]

I have made the requested changes; please review again

[bedevere-bot]

Thanks for making the requested changes!

@mdickinson: please review the changes made to this pull request.

[mdickinson]

Thank you for the updates! This LGTM, and works as advertised in manual testing.

I'll run this through the buildbots, and then if all's okay I'll merge.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @mdickinson for commit 5b6fd70 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

[mdickinson]

Two buildbot failures, neither of which looks relevant to the changes in this PR (one failure in test_cmd_line_script; one in test_capi). One buildbot has yet to report, but I think at this point it's safe to merge.

@yanjs Thank you for the contribution and for your patience!

[yanjs]

thanks