[haiku-commits] Re: r40492 - haiku/trunk/src/servers/net
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 18 Feb 2011 22:03:23 +0100
Philippe Houdoin <philippe.houdoin@xxxxxxxxx> wrote:
> > But that's specific to the inet_addr() function.
> > http://pubs.opengroup.org/onlinepubs/007908799/xns/netinetin.h.html
> > does not mention anything like that.
> True, but I still find interesting that the few functions that returns
> this kind of specific type are said to do it in network order.
> Plus the in_addr.s_addr field which is also said to be in network
> order is also of this type.
[...]
> I'll say that accepting an in_addr_t argument implies accepting it's
> value, loaded outside of your scope, is usually in network byte order.
> Like here:
>
> struct sockaddr_in address;
> address.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
>
> BNetworkAddress loopbackAddress;
> loopbackAddress.SetAddress(address.sin_addr.s_addr);
FWIW, you convinced me; I'll revert reverting the revert :-)
> As we enjoy C++, why not offer another variant taking an uint32_t
> instead, that would consider it in host order instead?
Unfortunately, C++ is too smart, and doesn't allow for that, as
in_addr_t is actually a typedef to uint32_t -- to the compiler, they
are both just unsigned int, though.
Bye,
Axel.
Other related posts:
