[Nut-upsdev] Re: [nut-commits] svn commit r714 - in trunk: . server

[Peter Selinger]

Arjen de Korte wrote:
> 
> > Arjen, I wonder about server/access.c, line 60-61:
> >
> >        return (IN6_IS_ADDR_V4MAPPED(ip6) &&
> >           ((((const u_int32_t *)ip6)[3] & (u_int32_t)prefix) ==
> > net->s_addr));
> >
> > Comparing this with line 38:
> >
> >       return((((struct sockaddr_in*)ip_addr)->sin_addr.s_addr &
> > htonl(prefix)) == ((struct sockaddr_in*)net_addr)->sin_addr.s_addr);
> >
> > I wonder if it shouldn't be htonl(prefix) in line 61, or perhaps
> > ntohl(net->s_addr) in line 61. I don't understand these data
> > structures well, and presumably the patch came from someone who tested
> > it on a little-endian machine, but it seems to me from inet(3) that:
> >
> > *.s_addr                          is in network byte order,
> > ((const u_int32_t *)ip6)[3]       is in network byte order (???)
> > prefix                            is in host byte order.
> >
> > I cannot find the man page for struct in6_addr, so I am not sure about
> > the byte order of ip6, but it seems that if it's a byte array
> > converted to a int32 array, it should be big-endian.
> 
> You could be right, I didn't look at this. And neither did I for most
> other things that were introduced with the IPv6 patch. I only have a
> little endian machine available for testing, so trying this out is not an
> option. All this juggling with casting data from one type to the the other
> made my head spin after a couple of hours. :-)
> 
> For me, the IPv6 patch seems to do what it needs to do, but it would be
> really useful to try this out on a big endian machine too.

Yes, but it is on little-endian machines where testing matters the
most, because network byte order is always big-endian. I.e., on a
big-endian machine, htonl() and ntohl() are no-ops.

-- Peter