Name: clC74495 Date: 10/22/98


There is a portability bug in JDK 1.1.3 src/solaris/net/multicast.c
dealing with host and network byte order. This bug is also present
in JDK 1.1.7 and 1.2beta4 as well.

In two functions in multicast.c, java_net_PlainDatagramSocketImpl_join()
and java_net_PlainDatagramSocketImpl_leave(), there is code that checks
whether an address is a multicast address. It looks like this:

       addrptr = unhand(mcast_address);

       mname.imr_multiaddr.s_addr = htonl( addrptr->address );
       if (!IN_MULTICAST(mname.imr_multiaddr.s_addr))
       {
         ...
       }

       ... do setsockopt() call using mname structure ...

This code switches the address from host to network byte order
using the htonl() call, before doing both the IN_MULTICAST test
and the setsockopt() call. But IN_MULTICAST() expects the address
to be in host order! It's effectively defined in <netinet/in.h>
to be (((long)(i) & 0xf0000000) == 0xe0000000), which is a host-endian-
dependent expression.

On little-endian platforms (such as Intel x86) this code does not
work, since htonl() changes the byte order of the address. On big-endian
platforms (such as SPARC), where both host and network byte order is
big-endian and htonl() is a no-op, it'll work fine.

Therefore, to be portable, multicast.c should be fixed to move the htonl()
call after the IN_MULTICAST test:
         
       addrptr = unhand(mcast_address);

       if (!IN_MULTICAST(addrptr->address))
       {
         ...
       }
       mname.imr_multiaddr.s_addr = htonl( addrptr->address );

       ... do setsockopt() call using mname structure ...

Remember the change must be done in two places.
(Review ID: 40955)
======================================================================