Hi,
Sorry for cross posting, but the plib-users mailing list seems to be mute.
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
|
