Andrew Falanga presented these words - circa 3/13/08 9:10 AM->

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

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?


_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to