=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=
=D1=81=D0=B0=D0=BB(a):
> >
> > ...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=
 is=20
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=
=20
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=
=20
says:

http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/include/endian_machde=
p.h

=2D--cut---
/*	$NetBSD: endian_machdep.h,v 1.1.8.1 2000/11/20 20:09:26 bouyer Exp $	*/

#define _BYTE_ORDER _LITTLE_ENDIAN

#ifdef __GNUC__

#include <machine/byte_swap.h>

#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)))

#endif
=2D--cut---

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 =
bit=20
closer to POSIX specs ?

// wbr