On Thursday 10 June 2004 14:08, Ian Zagorskih wrote:
> =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".
>=20
> 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.

Well, I challenge you to demonstrate how these are not "compatible".
in_{addr,port}_t are type _synonyms_ of uint{32,16}_t.  From an
application POV this should well be compatible, albeit you'd expect
an conforming implementation to do the latter.

> Should i include arpa/inet.h or sys/types.h is enough ?

The former is what the standard says.  NetBSD used to have issues
with <arpa/inet.h> requiring pre-requisite headers, but that has
been resolved in time for 2.0.  <sys/types.h> will work on NetBSD,
but it's not what a conforming applications should rely upon.

> Is in_port_t the same as uint16_t ?
> Is in_addr_t the same as uint32_t ?

Yes, see above.

> Why do i need to deal with in_xxx_t if i don't use them and all what i ne=
ed is=20
> to convert integer values between host/net byte orders ?
> Finally, is my choice portable ?

You don't have to.  The choice for in_{addr,port}_t was driven by
1) long resp. short integers not being the right choice for use in
wire protocols in the emerging post-ILP32 world, and 2) the group
which invented these was concerned with (Inter)network application
programming rather than the definition of an universal byte order
reversal interface.

> > 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.
>=20
> 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 :)

In this context, looking for IEEE 1003.1g and XNS5 should shed some
light on this.

> > 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.
>=20
> 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 m=
an=20
> says:
>=20
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/i386/include/endian_mach=
dep.h
>=20
> ---cut---
> /*	$NetBSD: endian_machdep.h,v 1.1.8.1 2000/11/20 20:09:26 bouyer Exp $	*/
>=20
> #define _BYTE_ORDER _LITTLE_ENDIAN
>=20
> #ifdef __GNUC__
>=20
> #include <machine/byte_swap.h>
>=20
> #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)))
>=20
> #endif
> ---cut---
>=20

> So input/output data types are in conflict with current POSIX specs.

=46irst, you've been talking about "compatibility" above without
describing what you happen to mean by this.  While this presumably
was an oversight of the developer who made the change to uint{32,16}_t
in <sys/endian.h>, it's not the "conflict" you're trying to make it
appear as.

> Anyway, all i wanted to know is:  is there some plans to change it to be =
a bit=20
> closer to POSIX specs ?

Sure, but that you didn't ask. :-) Again, as you perhaps have noticed
<sys/endian.h> was modified in 2001 already, but the machine-dependent
headers got missed somehow.  This is about to be fixed, but again,
it's not as much of an issue as you seem to believe.


=2D Klaus