From: yorickpeterse@... Date: 2015-02-26T11:36:32+00:00 Subject: [ruby-core:68322] [Ruby trunk - Bug #10908] [Open] Addrinfo.new appears to ignore the afamily argument when using a String for sockaddr Issue #10908 has been reported by Yorick Peterse. ---------------------------------------- Bug #10908: Addrinfo.new appears to ignore the afamily argument when using a String for sockaddr https://bugs.ruby-lang.org/issues/10908 * Author: Yorick Peterse * Status: Open * Priority: Normal * Assignee: * ruby -v: ruby 2.2.0p0 (2014-12-25 revision 49005) [x86_64-linux] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN ---------------------------------------- When creating a new `Addrinfo` instance the `new` class method appears to ignore the 2nd (afamily) argument and always sets it to `AF_INET`. Some examples: Socket::AF_INET # => 2 Addrinfo.new(Socket.sockaddr_in(80, 'localhost')).afamily # => 2 Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::AF_INET6).afamily # => 2 Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::PF_UNSPEC).afamily # => 2 Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::AF_IPX).afamily # => 2 Addrinfo.new(Socket.sockaddr_in(80, 'localhost'), Socket::AF_LOCAL).afamily # => 2 Is this correct, or is this a bug? The documentation states the following about this argument: > family is specified as an integer to specify the protocol family such as > Socket::PF_INET. It can be a symbol or a string which is the constant name > with or without PF_ prefix such as :INET, :INET6, :UNIX, "PF_INET", etc. If > omitted, PF_UNSPEC is assumed. I looked at the tests but couldn't find any specific examples of this behaviour. For Rubinius I ended up writing the following Rubyspec which currently passes on both Rubinius (you'll need the Git master branch for this, for now) and Ruby 2.2: . I've attached the spec as well in case the URL stops working. ---Files-------------------------------- initialize_spec.rb (3.68 KB) -- https://bugs.ruby-lang.org/