Network.Socket endian problem?

[Rich Neswold]

On 12/14/06, Tomasz Zielonka <tomasz.zielonka at gmail.com> wrote:
> On Thu, Dec 14, 2006 at 05:22:43PM +0100, Ferenc Wagner wrote:
> > Tomasz Zielonka <tomasz.zielonka at gmail.com> writes:
> >
> > > Who agrees with me that it would be nice if network libraries used host
> > > byte order in their interface? Or at least they could use an abstract
> > > data type, whose byte order would be unobservable.
> >
> > Why is this trapdoor present in the C library?
>
> I don't know.
> Maybe for efficiency?

The only mention I could find related to this is in W. Richards
Stevens' "Unix Network Programming":

     "In theory an implementation could store the fields in a socket
address structure in host byte order and then convert to and from the
network byte order when moving the fields to and from the protocol
headers, saving us from having to worry about this detail. But both
history and Posix.1g specify that certain fields in the socket address
structures be maintained in network byte order."

Not very satisfactory. But even if the socket address details were
hidden, the data itself may require a certain endianness. The htonl(),
et al. functions assist in this detail for C programmers. I didn't see
any functions in the Haskell Network or Marshall libraries that help
Haskell programmers write out network byte order values. I didn't
check any third party libraries yet.

-- 
Rich

AIM : rnezzy
ICQ : 174908475