gh-74895: getaddrinfo no longer raises OverflowError #2435
Conversation
Convert a numeric port number to a string without an intermediate C long. This prevents raising OverflowError if the port number is out of the C long range.
|
@serhiy-storchaka to pass checks, should I (a) wait till #2436 is merged, (b) relax test_getaddrinfo_overflow, or (c) rebase this onto #2436? |
There was a problem hiding this comment.
Test output:
`FAIL: test_getaddrinfo_overflow (test.test_socket.GeneralModuleTests)
Traceback (most recent call last):
File "/home/me/Documents/cpython/Lib/test/test_socket.py", line 1370, in test_getaddrinfo_overflow
socket.getaddrinfo(None, _testcapi.LONG_MAX + 1)
AssertionError: gaierror not raised
`
Please fix.
|
This PR is stale because it has been open for 30 days with no activity. |
github-actions
bot
removed
the
stale
|
This PR is stale because it has been open for 30 days with no activity. |
arhadthedev
changed the title
|
@giampaolo, @gpshead (as network experts) |
Some systems treat it as unsigned internally so ULONG_MAX+1 is needed, not LONG_MAX+1.
github-actions
bot
removed
the
stale
Also updates our canned getaddrinfo.c implementation to actually report an error for values outside of the u_short range it casts the value to instead of ignoring them.
gpshead
changed the title
I effectively reworked the test, we don't actually want an error behavior on specific numeric values as we had in the past, we just want to report and error if the underlying platform's getaddrinfo() call reports an error. Not all of them do, or at least not all at the same values. for all practical purposes I doubt it matters much. it'd be nice for values outside of 16-bit unsigned to be rejected, but that only makes strict sense for IPv4 and IPv6. Other protocols are free to treat numeric service names (aka port) differently. |
http://bugs.python.org/issue30710
Depends on http://bugs.python.org/issue30711 to pass test_getaddrinfo_overflow.