Network.Socket endian problem?

[Sigbjorn Finne]

Hi,

as you've time-consumingly discovered, Network.Socket.HostAddress
is represented in network byte order (something that's not well
documented, and a potential trap.)

You may want to consider using Network.Socket.inet_addr as
a constructor.

--sigbjorn

Rich Neswold wrote:
> Hello,
>
> I've written a program that uses UDP as its communication with other
> processes. It was built with GHC 6.4.1 on MacOS 10.4 (PowerPC) and
> works fine. When I moved the code to a Linux box (i386) and built it
> with GHC 6.6, it didn't work. The problems turns out to be,
> apparently, an endian problem. The socket is created with the
> following snippet:
>
> allocSocket :: IO Socket
> allocSocket =
>    do { s <- socket AF_INET Datagram 0
>         ; handle (\e -> sClose s >> throwIO e) $
>                       do { connect s (SockAddrInet 6802 0x7f000001)
>                            ; return s
>                            }
>         }
>
> On the Macintosh, the socket only receives packets from
> 127.0.0.1:6802, which is correct (and works). On the Linux machine,
> the socket only accepts packets from 1.0.0.127:6802. The data
> constructor SockAddrInet doesn't swap the bytes of the address
> (although it correctly swaps the bytes of the port number!)
>
> Changing the data constructor call to (SockAddrInet 6802 0x0100007f)
> makes it work on Linux, but not on MacOS 10.4. (You can see what the
> socket is bound to, on Linux, with "netstat -aun".)
>
> I don't have access to GHC 6.4.1 on a Linux box to determine whether
> this is a regression in 6.6 or simply an overlooked detail. Should I
> file a PR? Am I doing something wrong?
>