On Thu, Mar 13, 2008 at 11:45 AM, Patrick Mahan <[EMAIL PROTECTED]> wrote: > > > Andrew Falanga presented these words - circa 3/13/08 9:10 AM-> > > > Hi, > > 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 >
Ok, I should have thought of that when reading the manual. > > if ((res = inet_pton(AF_INET, "192.168.0.1", &sa.sin_addr)) < 0) > perror("inet_pton"); > > > Because it is treating the sockaddr_in structure as an in_addr structure > which is clobbering the sin_family field. > If this is true, then why are my packets sent at all? The definition of sockaddr_in (from /usr/include/netinet/in.h): 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]; }; The definition of in_addr (from /usr/include/netinet/in.h): struct in_addr { in_addr_t s_addr; }; The definition of in_addr_t (from /usr/include/netinet/in.h): typedef uint32_t in_addr_t; Passing in what I have, the address should indeed (as you've pointed out) clobber the sin_family member. However, since in_addr is basically an unsigned integer, i.e. 4 bytes wide, shouldn't inet_pton(3) clobber sin_len, sin_family & sin_port before ever reaching sin_addr? The sin_len & sin_family are 8 bit quantities, the sin_port is 16 bits, that's 32. If inet_pton(3) is expecting only an in_addr I would think that a call to sendto(2) would fail because the address in sin_addr is not filled, correct? Andy -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"