=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=
=D1=81=D0=B0=D0=BB(a):
>
> > 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=
hat=20
mostly this functions are used to convert Inet port and address values. But=
=20
when i implement some custom binary protocol based on TCP i'd like to follo=
w=20
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=
s=20
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=
ks=20
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=
ed=20
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=
=20
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=
me=20
other platform, for example NetBSD. Which also follows POSIX way and define=
d=20
pthread_t but does it in a different maner so here pthread_t is a pointer o=
n=20
some internal data structure. As a result, code which assumes that pthread_=
t=20
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=
t=20
conversation about this little problem..

What am i about.. After this and alike mistypos i'm treating things like "A=
 is=20
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=
ll=20
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