[Plib-users] Portability issue in plib 1.8.4 class netAddress

[Miguel L. S. R. <mi...@an...>]

Hi,

I've just joined this list to find out more about this issue.
I've come across plib several times as it is used as a base for several other
projects.
In this case, I came across this problem when trying to get FlightGear to work on FreeBSD;
whenever I tried to have it create a socket, it failed. I found out that it was failing with
the following error: Address family not supported by protocol family.
That's the message for EAFNOSUPPORT.

So, I checked the file src/net/netSocket.h in the underlaying plib-1.8.4, and found out
that a wrapper class is being used for sockaddr_in, the netAddress class (line 50 of the said
file).
I was a bit chocked by seeing that the layout of a structure which is supposed to be
internal to the OS was being reproduced in the layout of netAddress. The code is
as follows:

class netAddress
{
  /* DANGER!!!  This MUST match 'struct sockaddr_in' exactly! */
  short          sin_family     ;
  unsigned short sin_port       ;
  unsigned int   sin_addr       ;
  char           sin_zero [ 8 ] ;

Well, I cannot guess what reason took plib's designers to choose this strategy,
it would seem safer to me if a member variable of the type sockaddr_in existed inside
the netAddress class.
That way, the code would be protected from any differences in the layout of
sockaddr_in of different OSes.
All I can say is that in FreeBSD, the layout of sockaddr_in does not match that
structure. On FreeBSD, we have:

/* Socket address, internet style. */
struct sockaddr_in {
        uint8_t sin_len;
        sa_family_t     sin_family;
        in_port_t       sin_port;
        struct  in_addr sin_addr;
        char    sin_zero[8];
};

Of course, FreeBSD headers themselves are isolated from changes in the types
sa_family_t, etc... In practice, the only thing that differs is that the
two byte sin_family member is split into two members of one byte each, sin_len
and sin_family.
Because the i386 is a LSB first machine, filling the sin_family member of the
netAddress class will end up filling the sin_len member of sockaddr_in instead
of the sin_family member.

Therefore, any operations involving plib-1.8.4, AF_INET sockets and FreeBSD 7
fail with EAFNOSUPPORT. QED.

For my part, I would be happier if this would change, so I could play FlightGear
right out-of-the-ports-collection. Anyway, I'm curious about the rationale
behind this design issue. Could it be to avoid including OS specific headers?


Greetings,

Miguel Ramos
Lisboa, Portugal