You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've seen test failures for python package boto that uses HTTPPretty on my mipsel machines. It turns out that function fake_getaddrinfo from httppretty.core module hardcodes the values for socket family, type and protocol as integers 2, 1 and 6 respectively.
SOCK_DGRAM and SOCK_STREAM are system-specific constants. While you usually get
on some systems, you get different values. For example, on most MIPS linux systems, the values are:
$ uname -a
Linux loongson3 4.14.32-l3-def-alt1 #1 SMP PREEMPT Tue Apr 10 11:58:16 UTC 2018 mips64 GNU/Linux
$ python -c 'import socket; print "SOCK_DGRAM=%s SOCK_STREAM=%s" % (socket.SOCK_DGRAM, socket.SOCK_STREAM);'
SOCK_DGRAM=1 SOCK_STREAM=2
So, the value 1 from fake_addrinfo gets interpreted as SOCK_DGRAM on such machines, and tests fail as SOCK_DGRAM type is not supported with IPPROTO_TCP.
To avoid such issues, constants from socket modules should be consistently used instead of the integer values.
The text was updated successfully, but these errors were encountered:
iv-m
added a commit
to iv-m/HTTPretty
that referenced
this issue
Nov 2, 2018
SOCK_DGRAM and SOCK_STREAM are system-specific constants,
so we should use the constants from socket module instead
of having their value right in the code.
Closes: gabrielfalcao#358
Signed-off-by: Ivan A. Melnikov <iv@altlinux.org>
I've seen test failures for python package
boto
that uses HTTPPretty on my mipsel machines. It turns out that functionfake_getaddrinfo
fromhttppretty.core
module hardcodes the values for socket family, type and protocol as integers 2, 1 and 6 respectively.SOCK_DGRAM
andSOCK_STREAM
are system-specific constants. While you usually geton some systems, you get different values. For example, on most MIPS linux systems, the values are:
So, the value
1
fromfake_addrinfo
gets interpreted asSOCK_DGRAM
on such machines, and tests fail asSOCK_DGRAM
type is not supported withIPPROTO_TCP
.To avoid such issues, constants from
socket
modules should be consistently used instead of the integer values.The text was updated successfully, but these errors were encountered: