Network programming question

Patrick Mahan mahan at
Thu Mar 13 17:45:17 UTC 2008

Andrew Falanga presented these words - circa 3/13/08 9:10 AM->
> Hi,
> I'd like to know why the inet_pton(3) doesn't fill in the address
> family of the proper structure passed into it.  I'm at a complete loss
> for why.  Here's the prototype:
> int inet_pton(int af, const char * restrict src, void * restrict dst);
> Three arguments only.  The address family, hm, I'm passing it in; the
> address string in printable ASCII text, and a void pointer to the
> address structure to put the address into, presumably one of the
> sockaddr_* family structures for AF_INET or AF_INET6 (further, the man
> page says that this function is only valid for these two families now
> anyway).
>>From some coding for a program, I did find that this function,
> inet_pton(3), *does* in fact mangle the sin_family member of the
> sockaddr_in structure, so why not "mangle" it to what it should be?  I
> was doing something like this:
> // valid code above
> sockaddr_in   sa;
> sa.sin_family = AF_INET;
> sa.sin_port = htons(3252);
> inet_pton(AF_INET, "", &sa);
> sendto(sa, msg, strlen(msg), 0, (struct sockaddr*)&sa, sizeof(sa));

See man inet_pton . . . for details.

Briefly, inet_pton() doesn't understand sockaddr structures.  Instead,
it only understands in_addr or in6_addr structures which are included
inside the sockaddr structure.  So your above example should be changed

   // valid code above
   sockaddr_in sa;
   int res;

   sa.sin_family = AF_INET;
   sa.sin_port = htons(3252);

   if ((res = inet_pton(AF_INET, "", &sa.sin_addr)) < 0)

   if (!res)  // error occurred
     fprintf(stderr, "Address notation incorrect for AF_INET address\n");

> The call to sendto is wrapped in an if an was failing for errno code
> 47, Address family not supported by protocol (I was using UDP).  I
> changed the assignment of AF_INET to the sa.sin_family member to
> *after* the call to inet_pton(3) and suddenly everything worked.  Why?
>  Since the address family was used by inet_pton(3) to figure out how
> to read the address and assign it to sa.sin_addr.s_addr, why not
> simply assign AF_INET to the address family member in inet_pton(3)?

Because it is treating the sockaddr_in structure as an in_addr structure
which is clobbering the sin_family field.

> I'm not trying to be argumentative.  I'm just curious.  It seems like
> redundancy.  I've used the address family to tell inet_pton(3) how to
> operate, and then this function can't assign it to the sockaddr_in
> structure passed to it?  This makes little sense.  In case it's
> because I'm using older FBSD libraries that had a flaw fixed, I'm
> using FreeBSD 6.2-RELEASE-p4.  Is this because that's how POSIX
> defined it to work?  Is this the right venue or should I try one of
> the other mailing lists?



More information about the freebsd-questions mailing list