[Bug libc/644] New: incorrect address ordering by getaddrinfo in rule 9

["stroumf37 at yahoo dot ca" <sourceware-bugzilla at sources dot redhat dot com>]

When calling getaddrinfo on a host on my network, I get these addresses returned
in this order:

192.168.109.29
192.168.93.3
192.168.44.61
192.168.96.2
192.168.2.243
192.168.8.16
192.168.94.2

The host I'm calling getaddrinfo on has this address:
192.168.95.25

getaddrinfo should return 192.168.94.2 first, but doesn't.

I think the problem is in Rule 9 of the code where ffs is used.  Here is the
code from the IPv4 part of the rule:

  bit1 = ffs (in1_dst->sin_addr.s_addr ^ in1_src->sin_addr.s_addr);
  bit2 = ffs (in2_dst->sin_addr.s_addr ^ in2_src->sin_addr.s_addr);

and then

  if (bit1 > bit2)
	return -1;
  if (bit1 < bit2)
	return 1;

According to RFC 3484, the longest matching preffix gets higher precedence. 
Therefore, we actually do not want the first significat bit (right-most bit)
returned after the XOR of the addresses which is what ffs does, but the
left-most bit.  The code for IPv6 does basically the same thing.

-- 
           Summary: incorrect address ordering by getaddrinfo in rule 9
           Product: glibc
           Version: 2.3.3
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: stroumf37 at yahoo dot ca
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=644

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.