diff options
author | Rich Felker <dalias@aerifal.cx> | 2018-07-11 15:03:34 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2018-07-11 15:03:34 -0400 |
commit | 4f35eb7591031a1e5ef9828f9304361f282f28b9 (patch) | |
tree | 87631061e55eb527b03c66b921119038fa426c80 /src/math/powerpc64/lrintf.c | |
parent | b0d2b3a1e5820271c0f81d4c1fb8972a2f1141f5 (diff) | |
download | musl-4f35eb7591031a1e5ef9828f9304361f282f28b9.tar.gz musl-4f35eb7591031a1e5ef9828f9304361f282f28b9.tar.xz musl-4f35eb7591031a1e5ef9828f9304361f282f28b9.zip |
resolver: don't depend on v4mapped ipv6 to probe routability of v4 addrs
to produce sorted results roughly corresponding to RFC 3484/6724, __lookup_name computes routability and choice of source address via dummy UDP connect operations (which do not produce any packets). since at the logical level, the properties fed into the sort key are computed on ipv6 addresses, the code was written to use the v4mapped ipv6 form of ipv4 addresses and share a common code path for them all. however, on kernels where ipv6 support has been completely omitted, this causes ipv4 to appear equally unroutable as ipv6, thereby putting unreachable ipv6 addresses before ipv4 addresses in the results. instead, use only ipv4 sockets to compute routability for ipv4 addresses. some gratuitous conversion back and forth is left so that the logic is not affected by these changes. it may be possible to simplify the ipv4 case considerably, thereby reducing code size and complexity.
Diffstat (limited to 'src/math/powerpc64/lrintf.c')
0 files changed, 0 insertions, 0 deletions