Kurt Rose added the comment:
I think this may in fact be a bug. There are other places in the socket module
where port is checked, create_connection() just seems to have been missed.
create_connection() and socket.connect() have different behavior:
socket.create_connection( ('google.com
Kurt Rose added the comment:
I was incorrect -- the result of getsockname() appears to be some garbage port:
socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56446)
socket.create_connection( ('google.com', 2**16 + 80) ).getsockname()
('10.225.89.86', 56447
Kurt Rose added the comment:
Sorry, dumb mistake on my part. I should have been calling getpeername(), not
getsockname()
In that case the result is 80:
socket.create_connection( ('google.com', 2**16 + 80) ).getpeername()
('74.125.239.41', 80)
The random ports were the client-side ephemeral
New submission from Kurt Rose:
This appears to affect all versions of Python. In a behavior inherited from C,
TCP ports that are 2 bytes are silently truncated.
Here is a simple reproduction:
socket.create_connection( ('google.com', 2**16 + 80) )
socket.socket object, fd=408, family=2
Kurt Rose added the comment:
Totally agree this needs to be managed carefully. My goal here was just to
raise awareness and see if there is consensus that the behavior should be
changed.
I came across this because an upstream process had a bug which led to
impossible TCP ports being
New submission from Kurt Rose:
int() ignores everything after a null byte when reporting an error message.
Here you can see an example of how this manifests, and why could be a problem.
Python 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit(Intel)] on
win32
Type help, copyright
New submission from Kurt Rose:
The documentation in the resource module for get_page_size() is incorrect.
resource.getpagesize()
Returns the number of bytes in a system page. (This need not be the same as the
hardware page size.) This function is useful for determining the number of
bytes
