Subject: Re: htons - POSIX vs BSD
To: None <>
From: Ian Zagorskih <>
List: tech-userlevel
Date: 06/10/2004 22:12:58
=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 21:24 Klaus Klein =D0=BD=D0=B0=D0=BF=D0=B8=
> > Why do i need to deal with in_xxx_t if i don't use them and all what i
> > need is 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.

Of course and this is explicitly mentioned in both POSIX and NetBSD specs t=
mostly this functions are used to convert Inet port and address values. But=
when i implement some custom binary protocol based on TCP i'd like to follo=
network order rule and i need to do about the same convertions when=20
sending/receiving packets from the world. ATM i'v got used to use this call=
for own private tasks.

What's related to the question "in_port_t vs uint16_t" or "in_addr_t vs=20
uint32_t"... Several days ago i got quite interesting expericence which loo=
quite similar.

POSIX.1 for pthread library states that pthread_t must be defined in=20
<sys/types.h> and must be used for pthread_xxx() calls to identify thread.

Some old and very resepected and well-known Real-Time Operating System (end=
with X) which is willing to be "the-most-posix-compatible-rtos" defines=20
pthread_t as an integer type. Long, short or just int i don't know. So in=20
their own code and examples they freely use constructions like:

pthread_t id;
printf("thread id %d\n", id);

=2E..and of course it works just fine. Technically, until code works inside=
their environment this is correct course threads sub-system is completely=20
implemented inside kernel and userland apps operate only by thread indexes.

Problems started when i had to port code written with this OS in mind to so=
other platform, for example NetBSD. Which also follows POSIX way and define=
pthread_t but does it in a different maner so here pthread_t is a pointer o=
some internal data structure. As a result, code which assumes that pthread_=
is an integer becomes completely broken. And according to POSIX NetBSD is=20
correct course POSIX dosn't specify *how* exactly pthread_t must be=20
implemented and even states that it may be a pointer (see not so long ago=20
corrections to). Folks from development team were quite confused when we go=
conversation about this little problem..

What am i about.. After this and alike mistypos i'm treating things like "A=
assumed to be B [see implementation]" with big care. And if htons()=20
explicitly returns in_port_t i am not sure anymore that it is and always wi=
be same as uint16_t :) All's changing in time..

> 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.

Thanks, Klaus, i'v got the answer :)

// wbr