Network programming question

[Andrew Falanga]

On Thu, Mar 13, 2008 at 11:45 AM, Patrick Mahan <mahan at mahan.org> 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?