>> The definition of getpeername() used in the (currently unused)
>> LOGGING code segment calls for a "sockaddr_in sin" as the second
>> argument to getpeername().  The getpeername() man page says that the
>> second argumen= t=20 should be a sockaddr structure.

> It is because all networking functions (getpeername(), bind() and so
> on) take a struct sockaddr * as an argument and this structure is a
> generic address structure.  But in real life, one has to use a real
> structure suc= h as struct sockaddr_in which represent an IP address,
> port...  So those networking functions take in fact a struct
> sockaddr_in * casted as a stru= ct sockaddr *.  It is like that since
> a long time and it's perfectly OK.

Well, it's basically OK that they take a struct sockaddr and you're
supposed to pass a struct sockaddr_in or sockaddr_un or whatever is
appropriate for the address family in use, with an appropriate cast;
the kernel (which is what interprets that argument) knows you're doing
that and can ignore it on machines where there is no difference and
compensate for it on machines where one needs to do something to
compensate....

But that does not make it okay to declare getpeername() as taking a
struct sockaddr_in pointer.  The very parameter-passing mechanisms for
"struct sockaddr *" and "struct sockaddr_in *" may be utterly
different.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu