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, "192.168.0.1", &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
to
// valid code above
sockaddr_in sa;
int res;
sa.sin_family = AF_INET;
sa.sin_port = htons(3252);
if ((res = inet_pton(AF_INET, "192.168.0.1", &sa.sin_addr)) < 0)
perror("inet_pton");
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?
RTM,
Patrick
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
