the use sin_zero in sockaddr_in

the use sin_zero in sockaddr_in

[prabhu]

Hi all,

Could anyone please explain the use *sin_zero in *sockaddr_in?

struct sockaddr_in{
        short    sin_family;    /* AF_INET */
        u_short    sin_port;        /* 16-bit port number */
                    /* network byte ordered */
        struct in_addr sin_addr;    /* 32-bit netid/hostid */
                    /* network byte ordered */
*        char    sin_zero[8];    /* unused */*
}

Thanks,
Prabhu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110221/b24bbcef/attachment.html 

the use sin_zero in sockaddr_in

[Jose Celestino]

On Seg, 2011-02-21 at 21:41 +0530, prabhu wrote:
> Hi all,
> 
> Could anyone please explain the use sin_zero in sockaddr_in? 
> 

Padding to allow for casting.

-- 
Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc
----------------------------------------------------------------
"Assumption is the Mother of Screw-Up" -- Mr. John Elwood Hale

the use sin_zero in sockaddr_in

[prabhu]

Jose Celestino wrote:
> On Seg, 2011-02-21 at 21:41 +0530, prabhu wrote:
>   
>> Hi all,
>>
>> Could anyone please explain the use sin_zero in sockaddr_in? 
>>
>>     
>
> Padding to allow for casting.
>
>   
Hi Jose,

Could u please elaborate little more... why we  need this 8 byte padding.

My complete Question:
1. Actually total size of sockaddr_in is 16 byte and out of 16 byte why 
we have to use 8 byte for padding.?
2. Do we use these 8 byte for any other usage for real time?



Thanks,
Prabhu



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110221/9903a74b/attachment.html 

the use sin_zero in sockaddr_in

[Wick]

On Tue, Feb 22, 2011 at 12:34 AM, prabhu <prabhum@msys-tech.com> wrote:
> Jose Celestino wrote:
>
> On Seg, 2011-02-21 at 21:41 +0530, prabhu wrote:
>
>
> Hi all,
>
> Could anyone please explain the use sin_zero in sockaddr_in?
>
>
>
> Padding to allow for casting.
>
>
>
> Hi Jose,
>
> Could u please elaborate little more... why we? need this 8 byte padding.
>
> My complete Question:
> 1. Actually total size of sockaddr_in is 16 byte and out of 16 byte why we
> have to use 8 byte for padding.?
> 2. Do we use these 8 byte for any other usage for real time?

Unix network programming chapter 3.2 says that, "The POSIX
specification requires
only three members in the structure: sin_family, sin_addr, and sin_port. It is
acceptable for a POSIX-compliant implementation to define additional structure
members, and this is normal for an Internet socket address structure. Almost all
implementations add the sin_zero member so that all socket address structures
are at least 16 bytes in size. "

It's kinda like structure padding, maybe reserved for extra fields in the
future. You will never use it, just as commented.

-- 
Wick
MSN/GTalk: izhangxc[AT]gmail.com

the use sin_zero in sockaddr_in

[Wick]

On Tue, Feb 22, 2011 at 12:34 AM, prabhu <prabhum@msys-tech.com> wrote:
> Jose Celestino wrote:
>
> On Seg, 2011-02-21 at 21:41 +0530, prabhu wrote:
>
>
> Hi all,
>
> Could anyone please explain the use sin_zero in sockaddr_in?
>
>
>
> Padding to allow for casting.
>
>
>
> Hi Jose,
>
> Could u please elaborate little more... why we? need this 8 byte padding.
>
> My complete Question:
> 1. Actually total size of sockaddr_in is 16 byte and out of 16 byte why we
> have to use 8 byte for padding.?
> 2. Do we use these 8 byte for any other usage for real time?

Unix network programming chapter 3.2 says that, "The POSIX specification
requires only three members in the structure: sin_family, sin_addr, and
sin_port. It is acceptable for a POSIX-compliant implementation to define
additional structure members, and this is normal for an Internet socket address
structure. Almost all implementations add the sin_zero member so that all socket
address structures are at least 16 bytes in size. "

It's kinda like structure padding, maybe reserved for extra fields in the
future. You will never use it, just as commented.