Subject: Re: htons - POSIX vs BSD
To: None <email@example.com>
From: Ian Zagorskih <firstname.lastname@example.org>
Date: 06/10/2004 19:08:23
=D0=92 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B8 =D0=BE=D1=82 =
10 =D0=98=D1=8E=D0=BD=D1=8C 2004 18:26 Klaus Klein =D0=BD=D0=B0=D0=BF=D0=B8=
> > ...which is not compatible with POSIX declaration:
> > http://www.opengroup.org/onlinepubs/009695399/functions/htonl.html
> In this context, there's no formal definition of "compatible".
Cannot say about formal definition but this two specs define htox/xtoh=20
functions in two different ways. IMHO it's enough to be confused a bit.
Should i include arpa/inet.h or sys/types.h is enough ?
Is in_port_t the same as uint16_t ?
Is in_addr_t the same as uint32_t ?
Why do i need to deal with in_xxx_t if i don't use them and all what i need=
to convert integer values between host/net byte orders ?
=46inally, is my choice portable ?
> If you look at the history of these interfaces and don't ignore
> standardization efforts long before POSIX-2001 you'll find it not
> all that "weird", given the slow transition from short/long over
> in_port_t/in_addr_t to uint16_t/uint32_t.
Sorry, i'm not willing to ignore the history of standartization. For sure i=
would read it with interest if you drop me a link :)
> Now, in any case, if you have a look the implementation of these
> you'll find that NetBSD has been using the XNS5-style declarations
> for almost 3 years; it's just been missed to update the documentation
> at that time.
Maybe i don't understand something but if i got it right, for i386 actual=20
definitions are located in i386/endian_machdep.h and looks exactly like man=
/* $NetBSD: endian_machdep.h,v 126.96.36.199 2000/11/20 20:09:26 bouyer Exp $ */
#define _BYTE_ORDER _LITTLE_ENDIAN
#define ntohl(x) ((in_addr_t)__byte_swap_long((in_addr_t)(x)))
#define ntohs(x) ((in_port_t)__byte_swap_word((in_port_t)(x)))
#define htonl(x) ((in_addr_t)__byte_swap_long((in_addr_t)(x)))
#define htons(x) ((in_port_t)__byte_swap_word((in_port_t)(x)))
So input/output data types are in conflict with current POSIX specs.
Anyway, all i wanted to know is: is there some plans to change it to be a =
closer to POSIX specs ?