Any pointer to Byte Alignment & Structure Padding?

Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

Hi,
    Can any body provide some light on Byte Alignment & Structure Padding
for gcc linux x86 32-bit?

Regards,
Amit Dang

Any pointer to Byte Alignment & Structure Padding?

[Vadiraj]

On 8/1/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> Hi,
>    Can any body provide some light on Byte Alignment & Structure Padding
> for gcc linux x86 32-bit?

 The system expects the address of a variable to be multiple of
its size. Meaning for 32 bit x86 int being 4 bytes. The address
location of a int variable is expected to be at multiple of 4.
ex 0 4 8 12 16. if  its double then its expected it to be multiple of 8.
0 8 16 ...

 In case of structure allignment... this is achieved by padding.
if this is the structure
struct temp
{
      char c;   /* 1 byte lenght */
      int i;      /* 4 byte length */
      char c1; /* 1 byte length */
      long long d /* 8 bytes  lenght */
};

 c starts at offset x( x is assured 4 byte alligned by gcc), i should
start at x+4 as it has to be multiple of 4 3 bytes of padding will be
done by gcc.
c1 starts at x+9, no padding is required char is 1 byte.
d starts at x+16,7 bytes of padding to get multiple of 8.

It would differ if you re arrange the struct like this.
struct temp
{
      char c;   /* 1 byte lenght */
      int i;      /* 4 byte length */
      long long d /* 8 bytes  lenght */
      char c1;
};

for same base offset...i will be from x+4 d would start from x+8,
there would be no padding for d  and c1 at x+16.

I hope it helps.
--
cheers,
Vadi

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

Hi Vadiraj,
    Thanks for the explaination but when i try following structure
struct temp
 {
        char c;   /* 1 byte lenght */
        int i;      /* 4 byte length */
        char c1; /* 1 byte length */
        long long d /* 8 bytes  lenght */
 };
on a linux machine x86 32-bit with gcc 2.96. It gives its size = 20 bytes
not 24 bytes (as explained by you)

Regards,
Amit Dang

----- Original Message ----- 
From: "Vadiraj" <vadiraj.cs@gmail.com>
To: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>
Sent: Monday, August 01, 2005 5:44 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/1/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> > Hi,
> >    Can any body provide some light on Byte Alignment & Structure Padding
> > for gcc linux x86 32-bit?
>
>  The system expects the address of a variable to be multiple of
> its size. Meaning for 32 bit x86 int being 4 bytes. The address
> location of a int variable is expected to be at multiple of 4.
> ex 0 4 8 12 16. if  its double then its expected it to be multiple of 8.
> 0 8 16 ...
>
>  In case of structure allignment... this is achieved by padding.
> if this is the structure
> struct temp
> {
>        char c;   /* 1 byte lenght */
>        int i;      /* 4 byte length */
>        char c1; /* 1 byte length */
>        long long d /* 8 bytes  lenght */
> };
>
>  c starts at offset x( x is assured 4 byte alligned by gcc), i should
> start at x+4 as it has to be multiple of 4 3 bytes of padding will be
> done by gcc.
> c1 starts at x+9, no padding is required char is 1 byte.
> d starts at x+16,7 bytes of padding to get multiple of 8.
>
> It would differ if you re arrange the struct like this.
> struct temp
> {
>        char c;   /* 1 byte lenght */
>        int i;      /* 4 byte length */
>        long long d /* 8 bytes  lenght */
>        char c1;
> };
>
> for same base offset...i will be from x+4 d would start from x+8,
> there would be no padding for d  and c1 at x+16.
>
> I hope it helps.
> -- 
> cheers,
> Vadi

Re: Any pointer to Byte Alignment & Structure Padding?

[wwp]

Hello Amit,


On Mon, 1 Aug 2005 17:57:48 +0530 "Amit Dang"
<amit_dang@intersolutions.stpn.soft.net> wrote:

> Hi Vadiraj,
>     Thanks for the explaination but when i try following structure
> struct temp
>  {
>         char c;   /* 1 byte lenght */
>         int i;      /* 4 byte length */
>         char c1; /* 1 byte length */
>         long long d /* 8 bytes  lenght */
>  };
> on a linux machine x86 32-bit with gcc 2.96. It gives its size = 20 bytes
> not 24 bytes (as explained by you)

See below (this applies to both members sorting examples from Vadiraj):

struct           padded  offset
member     size  size    range
-------------------------------
c          1     4       0-3
i          4     4       4-7
c1         1     4       8-11
d          8     8       12-19

So, 20 bytes. Isn't it right?


Regards,

> ----- Original Message ----- 
> From: "Vadiraj" <vadiraj.cs@gmail.com>
> To: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>
> Sent: Monday, August 01, 2005 5:44 PM
> Subject: Re: Any pointer to Byte Alignment & Structure Padding?
> 
> 
> > On 8/1/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> > > Hi,
> > >    Can any body provide some light on Byte Alignment & Structure Padding
> > > for gcc linux x86 32-bit?
> >
> >  The system expects the address of a variable to be multiple of
> > its size. Meaning for 32 bit x86 int being 4 bytes. The address
> > location of a int variable is expected to be at multiple of 4.
> > ex 0 4 8 12 16. if  its double then its expected it to be multiple of 8.
> > 0 8 16 ...
> >
> >  In case of structure allignment... this is achieved by padding.
> > if this is the structure
> > struct temp
> > {
> >        char c;   /* 1 byte lenght */
> >        int i;      /* 4 byte length */
> >        char c1; /* 1 byte length */
> >        long long d /* 8 bytes  lenght */
> > };
> >
> >  c starts at offset x( x is assured 4 byte alligned by gcc), i should
> > start at x+4 as it has to be multiple of 4 3 bytes of padding will be
> > done by gcc.
> > c1 starts at x+9, no padding is required char is 1 byte.
> > d starts at x+16,7 bytes of padding to get multiple of 8.
> >
> > It would differ if you re arrange the struct like this.
> > struct temp
> > {
> >        char c;   /* 1 byte lenght */
> >        int i;      /* 4 byte length */
> >        long long d /* 8 bytes  lenght */
> >        char c1;
> > };
> >
> > for same base offset...i will be from x+4 d would start from x+8,
> > there would be no padding for d  and c1 at x+16.
> >
> > I hope it helps.
> > -- 
> > cheers,
> > Vadi
> 
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
wwp

Re: Any pointer to Byte Alignment & Structure Padding?

[Progga]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Tue, Aug 02, 2005 at 03:02:35PM +0530, Amit Dang wrote:

>     You are very right in saying that "there is no need for structures to
> have same layout on different platform" until structures are being written
> directly to the file system. But many time there is a requirement that the
> data file can be moved across platforms.

 In that case use __attribute__ ((packed)) after the structure definition.
There'll be no alignment then and the size will always be the same.

	struct hihi{
		int a ;
		char b ;
	} __attribute__ ((packed)) ;


[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: Any pointer to Byte Alignment & Structure Padding?

[Vadiraj]

On 8/2/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> 
> Vadiraj wrote:
> 
> > >    Can any body provide some light on Byte Alignment & Structure Padding
> > > for gcc linux x86 32-bit?
> >
> >  The system expects the address of a variable to be multiple of
> > its size. Meaning for 32 bit x86 int being 4 bytes. The address
> > location of a int variable is expected to be at multiple of 4.
> > ex 0 4 8 12 16. if  its double then its expected it to be multiple of 8.
> > 0 8 16 ...
> 
> Incorrect; 8-byte quantities (double and long long) are only 4-byte
> aligned, not 8-byte aligned.

 Depends on compiler and architecture. With GCC 3.3.3 on cygwin I get
24 bytes for the same structe and also in Solaris system too.
meaning 8 byte alligned. 

True that Gcc 2.9 on linux is 4 byte alligned.


-- 
cheers,
Vadi

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/2/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> Hi Glynn,
>    You are very right in saying that "there is no need for structures to
> have same layout on different platform" until structures are being written
> directly to the file system. But many time there is a requirement that the
> data file can be moved across platforms.

Reading and writing binary files in a portable way is not possible as
is.  Unless it is absolutely necessary to read/write binary data you
should always prefer a portable solution like XML and its derivatives.

An easy way to improve portability of binary files is to prepend a
header that contains enough information to discover byte ordering,
floating-point format, etc.  That makes it easy enough to write simple
tools that are able to read/write binary data.

All other techniques used for binary data are quite complex and rely
on other (quasi-)standards like XDR (invented by Sun and used for NFS
and RPC), CCITT X.409 or ASN.1.  They can be seen as a meta-languages
that specify the data representation for particular file formats.
 
> ----- Original Message -----
> From: "Glynn Clements" <glynn@gclements.plus.com>
> To: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>
> Cc: <linux-c-programming@vger.kernel.org>
> Sent: Tuesday, August 02, 2005 4:24 PM
> Subject: Re: Any pointer to Byte Alignment & Structure Padding?
> 
> 
> >
> > Amit Dang wrote:
> >
> > > Thanks Steve. So what is the best way of laying down a structure
> definition
> > > to over come cross platform issues?
> > > I read about introducing some explicit padding in the structure to take
> care
> > > for cross platform issues but for that I suppose one should have
> information
> > > about byte alignment & structure padding on all targeted platforms. Is
> that
> > > true or there is some generic way of doing that? (Apart from using
> compiler
> > > option to remove any padding )
> >
> > Structure layout has nothing to do with portability. There's no reason
> > why a structure needs to have the same layout on different platforms.
> > In most situations, you don't need to know anything about how the
> > structure is laid out; you just reference the fields.
> >
> > --
> > Glynn Clements <glynn@gclements.plus.com>
> > -
> > To unsubscribe from this list: send the line "unsubscribe
> linux-c-programming" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
                                 ______________________________________
Steve Graegert                  //
Software Consultancy           //    Whether you know it or not, if you
Mobile: +49 (176)  21248869   // are a hacker, you are a revolutionary.   
Office: +49 (9131) 7126409   //  Don't worry, you're on the right side.
____________________________//         -- Dr Crash / Phrack 6 / phile 3

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

Hi Progga,
    Thanks for the reply. Yes, __attribute__(packed) can be used but that
comes with processing overhead. I read some where on net (I am not very sure
about that), all compilers do not support such construct.

Regards,
Amit Dang
----- Original Message ----- 
From: "Progga" <abulfazl@juniv.edu>
To: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>
Cc: <linux-c-programming@vger.kernel.org>
Sent: Tuesday, August 02, 2005 4:38 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?
On Tue, Aug 02, 2005 at 03:02:35PM +0530, Amit Dang wrote:

>     You are very right in saying that "there is no need for structures to
> have same layout on different platform" until structures are being written
> directly to the file system. But many time there is a requirement that the
> data file can be moved across platforms.

 In that case use __attribute__ ((packed)) after the structure definition.
There'll be no alignment then and the size will always be the same.

 struct hihi{
  int a ;
  char b ;
 } __attribute__ ((packed)) ;

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

Hi Vadiraj,
    Thanks for the reply. So any idea about how structure should be defined
in case it is to be used by a text file editor which works on both linux &
solaris.

Regards,
Amit Dang
----- Original Message ----- 
From: "Vadiraj" <vadiraj.cs@gmail.com>
To: "Glynn Clements" <glynn@gclements.plus.com>
Cc: "linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Tuesday, August 02, 2005 4:51 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/2/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> >
> > Vadiraj wrote:
> >
> > > >    Can any body provide some light on Byte Alignment & Structure
Padding
> > > > for gcc linux x86 32-bit?
> > >
> > >  The system expects the address of a variable to be multiple of
> > > its size. Meaning for 32 bit x86 int being 4 bytes. The address
> > > location of a int variable is expected to be at multiple of 4.
> > > ex 0 4 8 12 16. if  its double then its expected it to be multiple of
8.
> > > 0 8 16 ...
> >
> > Incorrect; 8-byte quantities (double and long long) are only 4-byte
> > aligned, not 8-byte aligned.
>
>  Depends on compiler and architecture. With GCC 3.3.3 on cygwin I get
> 24 bytes for the same structe and also in Solaris system too.
> meaning 8 byte alligned.
>
> True that Gcc 2.9 on linux is 4 byte alligned.
>
>
> -- 
> cheers,
> Vadi
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Any pointer to Byte Alignment & Structure Padding?

[Glynn Clements]

Amit Dang wrote:

>     Thanks for the reply. So any idea about how structure should be defined
> in case it is to be used by a text file editor which works on both linux &
> solaris.

However you like.

You shouldn't be trying to read blocks of data from a file directly
into a C "struct" in memory. That technique is fine for "internal"
files which only need to be read by one version of the software on one
particular platform, but it's the wrong approach for "interchange"
files which can be transferred between different systems or different
versions of the software.

For interchange formats, rather than making assumptions about the
size, offset and byte order of structure fields, you should either
write your own decoding and encoding routines or use a standard data
encoding (e.g. XDR, ASN.1 etc).

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Any pointer to Byte Alignment & Structure Padding?

[Vadiraj]

On 8/2/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> 
> Amit Dang wrote:
> 
> >     Thanks for the reply. So any idea about how structure should be defined
> > in case it is to be used by a text file editor which works on both linux &
> > solaris.
> 
> However you like.
> 
> You shouldn't be trying to read blocks of data from a file directly
> into a C "struct" in memory. That technique is fine for "internal"
> files which only need to be read by one version of the software on one
> particular platform, but it's the wrong approach for "interchange"
> files which can be transferred between different systems or different
> versions of the software.
> 
> For interchange formats, rather than making assumptions about the
> size, offset and byte order of structure fields, you should either
> write your own decoding and encoding routines or use a standard data
> encoding (e.g. XDR, ASN.1 etc).

 May be you could align your structure such a way that compiler does
not have to do any padding. In that case you would not face any
problem across different platforms.

for the same example arranging it this way would give 16 bytes on all
32 bit compilers..

struct temp
{
   long long l;
    int i;
   char c;
   char c1;
}; /* this example would still gets padded at the end. If you could
avoid this too,
you are safe */

 Best way that I would prefer would be read byte wise and form the
structure peacefully instead of direct struct read.




-- 
cheers,
Vadi

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

Reading byte wise won't help any way. Its both reading and writing.
Structure in that case should be written field wise. Moreover in this case
we need to take care of size of different types, floating point format, etc.
Its tough!!
----- Original Message ----- 
From: "Vadiraj" <vadiraj.cs@gmail.com>
To: "Glynn Clements" <glynn@gclements.plus.com>
Cc: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>;
"linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Tuesday, August 02, 2005 10:42 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/2/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> >
> > Amit Dang wrote:
> >
> > >     Thanks for the reply. So any idea about how structure should be
defined
> > > in case it is to be used by a text file editor which works on both
linux &
> > > solaris.
> >
> > However you like.
> >
> > You shouldn't be trying to read blocks of data from a file directly
> > into a C "struct" in memory. That technique is fine for "internal"
> > files which only need to be read by one version of the software on one
> > particular platform, but it's the wrong approach for "interchange"
> > files which can be transferred between different systems or different
> > versions of the software.
> >
> > For interchange formats, rather than making assumptions about the
> > size, offset and byte order of structure fields, you should either
> > write your own decoding and encoding routines or use a standard data
> > encoding (e.g. XDR, ASN.1 etc).
>
>  May be you could align your structure such a way that compiler does
> not have to do any padding. In that case you would not face any
> problem across different platforms.
>
> for the same example arranging it this way would give 16 bytes on all
> 32 bit compilers..
>
> struct temp
> {
>    long long l;
>     int i;
>    char c;
>    char c1;
> }; /* this example would still gets padded at the end. If you could
> avoid this too,
> you are safe */
>
>  Best way that I would prefer would be read byte wise and form the
> structure peacefully instead of direct struct read.

Re: Any pointer to Byte Alignment & Structure Padding?

[Vadiraj]

On 8/4/05, Prabhat Hegde <pubs.hegde@gmail.com> wrote:
> According to what you have said, dont you think it depnds from which
> address your affset begins.
>   Considring your last example,
>    struct temp
> > {
> >       char c;   /* 1 byte lenght */
> >       int i;      /* 4 byte length */
> >       long long d /* 8 bytes  lenght */
> >       char c1;
> > };
> 
>   Since char (1 byte ) can start anywhere withour padding,
>   Lets take x to be at address X wherein (X mod 4 = 3), then in that
> case "i" will have no padding since char (1 byte ) will make the
> starting address of the int to agree with a 4 byte boundary.
>   Now again the next long having a 8 byte boundary willl be/ may not
> be padded depanding on the starting address.
>  So what i feel is that begin the variable which has the maximum byte
> boundary requirement. Now since all nos divisible by 8 are divisible
> by 4, we will be cutting out the padding for int. Char can come in the
> last.

  The starting address is assured to be 4 byte boundary. Some
compilers provide 8 byte boundary too. They never start with 1 byte
boundary.

That is the reason why the structure gets padded even at the end. To make it 
4 bytes alligned.


>   hence what if the structure is like the below:
>    struct temp{
>        long lond d;   // x + padding if required to suffice 8 byte boundary
>        int i;             // no padding
>        char c;         // no padding
>        char c1;       // no padding
>        };

  For this example the size should come to 8+4+1+1=14 bytes. But when
you check it will be 16 bytes. Due to padding, to make it 4/8 byte
boundry.
 
Take it for granted you get either 4 byte or 8 byte boundry but never 1 byte. 

Arranging the structure as mentioned above will definitely remove
portablility issue
as for both 4 byte or 8 byte aligned compilers the size will be 16 bytes.

-- 
cheers,
Vadi

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/4/05, Vadiraj <vadiraj.cs@gmail.com> wrote:
> On 8/4/05, Prabhat Hegde <pubs.hegde@gmail.com> wrote:

[snip]

> Arranging the structure as mentioned above will definitely remove
> portablility issue
> as for both 4 byte or 8 byte aligned compilers the size will be 16 bytes.

What about endianess? 

Regards

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

Hi Vadiraj,
The statement " Take it for granted you get either 4 byte or 8 byte boundary
but never 1 byte." you made is it generic or just valid for the structure in
question? If its generic then I have a question.
Why the size of
struct {
    char i;
    char j;
    char k;
} is 3 ? (gcc 2.96 on Linux 32-bit machine).
What I have understood atleast for gcc compiler Linux 32-bit machine is
that, Maximum byte boundary is 4. Structure will be aligned to byte boundary
equal to minimum of (4 or field with maximum size (within the structure)).
i.e. for the above example maximum field size if 1 and min (4, 1) = 1, so
structure is aligned to 1 byte.
If I have following structure
struct {
    short i;
    char j;
} its size will be 4.

if i modify the above struct to
struct {
    int i;
    char j;
} its size will be 8.
Now modifying int to long long in the above structure will have a size of
12 not 16 because byte alignment min (4, 8) = 4.

Assumptions: sizeof(char) = 1 byte, sizeof(short) = 2 byte, sizeof(int) = 4
byte, sizeof(long long) = 8 bytes.
Valid for gcc 2.96 Linux 32-bit machine

Regards,
Amit Dang
Regards,
Amit Dang


----- Original Message ----- 
From: "Vadiraj" <vadiraj.cs@gmail.com>
To: "Prabhat Hegde" <pubs.hegde@gmail.com>
Cc: "linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Thursday, August 04, 2005 8:53 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/4/05, Prabhat Hegde <pubs.hegde@gmail.com> wrote:
> > According to what you have said, dont you think it depnds from which
> > address your affset begins.
> >   Considring your last example,
> >    struct temp
> > > {
> > >       char c;   /* 1 byte lenght */
> > >       int i;      /* 4 byte length */
> > >       long long d /* 8 bytes  lenght */
> > >       char c1;
> > > };
> >
> >   Since char (1 byte ) can start anywhere withour padding,
> >   Lets take x to be at address X wherein (X mod 4 = 3), then in that
> > case "i" will have no padding since char (1 byte ) will make the
> > starting address of the int to agree with a 4 byte boundary.
> >   Now again the next long having a 8 byte boundary willl be/ may not
> > be padded depanding on the starting address.
> >  So what i feel is that begin the variable which has the maximum byte
> > boundary requirement. Now since all nos divisible by 8 are divisible
> > by 4, we will be cutting out the padding for int. Char can come in the
> > last.
>
>   The starting address is assured to be 4 byte boundary. Some
> compilers provide 8 byte boundary too. They never start with 1 byte
> boundary.
>
> That is the reason why the structure gets padded even at the end. To make
it
> 4 bytes alligned.
>
>
> >   hence what if the structure is like the below:
> >    struct temp{
> >        long lond d;   // x + padding if required to suffice 8 byte
boundary
> >        int i;             // no padding
> >        char c;         // no padding
> >        char c1;       // no padding
> >        };
>
>   For this example the size should come to 8+4+1+1=14 bytes. But when
> you check it will be 16 bytes. Due to padding, to make it 4/8 byte
> boundry.
>
> Take it for granted you get either 4 byte or 8 byte boundry but never 1
byte.
>
> Arranging the structure as mentioned above will definitely remove
> portablility issue
> as for both 4 byte or 8 byte aligned compilers the size will be 16 bytes.
>
> -- 
> cheers,
> Vadi
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/5/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> Hi Vadiraj,
> The statement " Take it for granted you get either 4 byte or 8 byte boundary
> but never 1 byte." you made is it generic or just valid for the structure in
> question? If its generic then I have a question.
> Why the size of
> struct {
>    char i;
>    char j;
>    char k;
> } is 3 ? (gcc 2.96 on Linux 32-bit machine).

Because the alignment requirement for this structure is 1, it is
byte-aligned.  A structure is padded and properly aligned only if one
of its members requires more than a single byte of storage. Take a
look at this:

	struct a {
		char  a;
		int    :0;
		char  b;
	};

its size is 3, since it's byte-aligned also.  This rule does not hold
for the structure

	struct b {
		char  a;
		short s;
	}

since one member, here s, requires more than one byte of storage and
must be aligned to a 4 byte boundary (4 is the smallest possible
multiple of 2 larger than 3) resulting in sizeof(b) == 4.

> What I have understood atleast for gcc compiler Linux 32-bit machine is
> that, Maximum byte boundary is 4.

True for int, but double and long long will always be 8 byte aligned by default.

> equal to minimum of (4 or field with maximum size (within the structure)).
> i.e. for the above example maximum field size if 1 and min (4, 1) = 1, so
> structure is aligned to 1 byte.
> If I have following structure
> struct {
>    short i;
>    char j;
> } its size will be 4.

True.
 
> if i modify the above struct to
> struct {
>    int i;
>    char j;
> } its size will be 8.

Yes, exactly.

> Now modifying int to long long in the above structure will have a size of
> 12 not 16 because byte alignment min (4, 8) = 4.

No, it will have a size of 16 because the alignment requirement for
this structure is a multiple of its largest member.  long long and
double is always double word aligned.

Regards

	\Steve

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

Hi Steve,
    Thanks for your prompt response and the valuable information. But I
tried following on Linux 32-bit gcc 2.96
struct temp {
    long long i;
    char c;
} and sizeof(struct temp) gave 12 not 16.

Regards,
Amit Dang

----- Original Message ----- 
From: "Steve Graegert" <graegerts@gmail.com>
To: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>
Cc: "linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Friday, August 05, 2005 12:02 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/5/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> > Hi Vadiraj,
> > The statement " Take it for granted you get either 4 byte or 8 byte
boundary
> > but never 1 byte." you made is it generic or just valid for the
structure in
> > question? If its generic then I have a question.
> > Why the size of
> > struct {
> >    char i;
> >    char j;
> >    char k;
> > } is 3 ? (gcc 2.96 on Linux 32-bit machine).
>
> Because the alignment requirement for this structure is 1, it is
> byte-aligned.  A structure is padded and properly aligned only if one
> of its members requires more than a single byte of storage. Take a
> look at this:
>
> struct a {
> char  a;
> int    :0;
> char  b;
> };
>
> its size is 3, since it's byte-aligned also.  This rule does not hold
> for the structure
>
> struct b {
> char  a;
> short s;
> }
>
> since one member, here s, requires more than one byte of storage and
> must be aligned to a 4 byte boundary (4 is the smallest possible
> multiple of 2 larger than 3) resulting in sizeof(b) == 4.
>
> > What I have understood atleast for gcc compiler Linux 32-bit machine is
> > that, Maximum byte boundary is 4.
>
> True for int, but double and long long will always be 8 byte aligned by
default.
>
> > equal to minimum of (4 or field with maximum size (within the
structure)).
> > i.e. for the above example maximum field size if 1 and min (4, 1) = 1,
so
> > structure is aligned to 1 byte.
> > If I have following structure
> > struct {
> >    short i;
> >    char j;
> > } its size will be 4.
>
> True.
>
> > if i modify the above struct to
> > struct {
> >    int i;
> >    char j;
> > } its size will be 8.
>
> Yes, exactly.
>
> > Now modifying int to long long in the above structure will have a size
of
> > 12 not 16 because byte alignment min (4, 8) = 4.
>
> No, it will have a size of 16 because the alignment requirement for
> this structure is a multiple of its largest member.  long long and
> double is always double word aligned.
>
> Regards
>
> \Steve

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/5/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> Hi Steve,
>    Thanks for your prompt response and the valuable information. But I
> tried following on Linux 32-bit gcc 2.96
> struct temp {
>    long long i;
>    char c;
> } and sizeof(struct temp) gave 12 not 16.

Hmm, I have no access to a 32-bit machine right now, but I am running
GCC 3.4.2 on SPARC and sizeof(temp) gives 16 as expected.

One thing a could think of is that on 32-bit machines it makes no
sense to pad to 16 bytes since the natural word size (size of internal
registers) is 4 bytes resulting in an unnecessary read operation to
fetch the rest of the structure that is useless anyway.

Regards

	\Steve

PS: I am going to investigate this issue when I return to my lab and
will mail you the results privately if you don't mind.

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/5/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> 
> Steve Graegert wrote:
> 
> > >    Thanks for your prompt response and the valuable information. But I
> > > tried following on Linux 32-bit gcc 2.96
> > > struct temp {
> > >    long long i;
> > >    char c;
> > > } and sizeof(struct temp) gave 12 not 16.
> >
> > Hmm, I have no access to a 32-bit machine right now, but I am running
> > GCC 3.4.2 on SPARC and sizeof(temp) gives 16 as expected.
> 
> long long is likely to be 8-byte aligned on 64-bit systems and 4-byte
> aligned on 32-bit systems.

Agree.  Interestingly, Microsofts VCC (was quite curious, so I did a
quick test) aligns long long on an 8-byte boundary resulting in a size
of 16 for the structure given above. (Yes it's a 32-bit machine.) 
Don't know the reason for that, since the ABI for i386 does not
mention this case explicitly.

> > One thing a could think of is that on 32-bit machines it makes no
> > sense to pad to 16 bytes since the natural word size (size of internal
> > registers) is 4 bytes resulting in an unnecessary read operation to
> > fetch the rest of the structure that is useless anyway.
> 
> Aligment is determined by the granularity of RAM access. E.g. 32-bit
> systems tend to have RAM organised as 32-bit words; reading a 32-bit
> value which issn't aligned requires reading two adjacent words,
> shifting and OR-ing them together to obtain the desired value.

Yes, sure, but why would Microsoft's C compiler generate code that
results in a fully despensable read operation for the padded word?  (I
know this is a Linux programming list, but the question seems related
to the overall topic of data alignment in memory.)
 
Regards

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

This should not happen until compiler option /Zp is explicitly set to 8.
Quoted from msdn
" ANSI 3.5.2.1   The padding and alignment of members of structures and
whether a bit field can straddle a storage-unit boundary
Structure members are stored sequentially in the order in which they are
declared: the first member has the lowest memory address and the last member
the highest.
Every data object has an alignment-requirement. The alignment-requirement
for all data except structures, unions, and arrays is either the size of the
object or the current packing size (specified with either /Zp or the pack
pragma, whichever is less). For structures, unions, and arrays, the
alignment-requirement is the largest alignment-requirement of its members.
Every object is allocated an offset so that
offset % alignment-requirement == 0
Adjacent bit fields are packed into the same 1-, 2-, or 4-byte allocation
unit if the integral types are the same size and if the next bit field fits
into the current allocation unit without crossing the boundary imposed by
the common alignment requirements of the bit fields. "
Source Url:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/impdf_34.asp

Regards,
Amit Dang
----- Original Message ----- 
From: "Steve Graegert" <graegerts@gmail.com>
To: "Glynn Clements" <glynn@gclements.plus.com>
Cc: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>;
"linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Friday, August 05, 2005 3:45 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/5/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> >
> > Steve Graegert wrote:
> >
> > > >    Thanks for your prompt response and the valuable information. But
I
> > > > tried following on Linux 32-bit gcc 2.96
> > > > struct temp {
> > > >    long long i;
> > > >    char c;
> > > > } and sizeof(struct temp) gave 12 not 16.
> > >
> > > Hmm, I have no access to a 32-bit machine right now, but I am running
> > > GCC 3.4.2 on SPARC and sizeof(temp) gives 16 as expected.
> >
> > long long is likely to be 8-byte aligned on 64-bit systems and 4-byte
> > aligned on 32-bit systems.
>
> Agree.  Interestingly, Microsofts VCC (was quite curious, so I did a
> quick test) aligns long long on an 8-byte boundary resulting in a size
> of 16 for the structure given above. (Yes it's a 32-bit machine.)
> Don't know the reason for that, since the ABI for i386 does not
> mention this case explicitly.
>
> > > One thing a could think of is that on 32-bit machines it makes no
> > > sense to pad to 16 bytes since the natural word size (size of internal
> > > registers) is 4 bytes resulting in an unnecessary read operation to
> > > fetch the rest of the structure that is useless anyway.
> >
> > Aligment is determined by the granularity of RAM access. E.g. 32-bit
> > systems tend to have RAM organised as 32-bit words; reading a 32-bit
> > value which issn't aligned requires reading two adjacent words,
> > shifting and OR-ing them together to obtain the desired value.
>
> Yes, sure, but why would Microsoft's C compiler generate code that
> results in a fully despensable read operation for the padded word?  (I
> know this is a Linux programming list, but the question seems related
> to the overall topic of data alignment in memory.)
>
> Regards
>
> \Steve
>
> --
>
> Steve Graegert <graegerts@gmail.com>
> Software Consultancy {C/C++ && Java && .NET}
> Mobile: +49 (176)  21248869
> Office: +49 (9131) 7126409
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/5/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> This should not happen until compiler option /Zp is explicitly set to 8.
> Quoted from msdn

[snipped very useful info]

Thanks for the pointer.  After checking the command line switches (/Zp
was not set) and removing any optimizing option the result did not
change.  I actually don't care very much about the MS way things are
done, but it seems they follow their own logic.

Regards

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409

Re: Any pointer to Byte Alignment & Structure Padding?

[Glynn Clements]

Steve Graegert wrote:

> >    Thanks for your prompt response and the valuable information. But I
> > tried following on Linux 32-bit gcc 2.96
> > struct temp {
> >    long long i;
> >    char c;
> > } and sizeof(struct temp) gave 12 not 16.
> 
> Hmm, I have no access to a 32-bit machine right now, but I am running
> GCC 3.4.2 on SPARC and sizeof(temp) gives 16 as expected.

long long is likely to be 8-byte aligned on 64-bit systems and 4-byte
aligned on 32-bit systems.

> One thing a could think of is that on 32-bit machines it makes no
> sense to pad to 16 bytes since the natural word size (size of internal
> registers) is 4 bytes resulting in an unnecessary read operation to
> fetch the rest of the structure that is useless anyway.

Aligment is determined by the granularity of RAM access. E.g. 32-bit
systems tend to have RAM organised as 32-bit words; reading a 32-bit
value which issn't aligned requires reading two adjacent words,
shifting and OR-ing them together to obtain the desired value.

Some architectures (e.g. x86) can do unaligned access at the CPU
level, in which case unaligned access is merely a performance hit. 
Other architectures (e.g. most RISC CPUs) can't; if you try to
read/write an unaligned address, the CPU generates an exception. In
this case, if you want to perform an unaligned access, you have to do
it in software.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Any pointer to Byte Alignment & Structure Padding?

[Amit Dang]

I just check /Zp by default is set to 8 not 4 ( which i read some where).
Moreover all libraries are also compiled with /Zp8. Changing it to some
other value raises a warning "compiler option 'structure packing (/Zp)'
inconsistent with precompiled header; current command-line option ignored".

Regards,
Amit Dang
----- Original Message ----- 
From: "Steve Graegert" <graegerts@gmail.com>
To: "Amit Dang" <amit_dang@intersolutions.stpn.soft.net>
Cc: "linux-c-programming" <linux-c-programming@vger.kernel.org>
Sent: Friday, August 05, 2005 4:43 PM
Subject: Re: Any pointer to Byte Alignment & Structure Padding?


> On 8/5/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> > This should not happen until compiler option /Zp is explicitly set to 8.
> > Quoted from msdn
>
> [snipped very useful info]
>
> Thanks for the pointer.  After checking the command line switches (/Zp
> was not set) and removing any optimizing option the result did not
> change.  I actually don't care very much about the MS way things are
> done, but it seems they follow their own logic.
>
> Regards
>
> \Steve

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/5/05, Glynn Clements <glynn@gclements.plus.com> wrote:
> 
> Steve Graegert wrote:
> 
> > > long long is likely to be 8-byte aligned on 64-bit systems and 4-byte
> > > aligned on 32-bit systems.
> >
> > Agree.  Interestingly, Microsofts VCC (was quite curious, so I did a
> > quick test) aligns long long on an 8-byte boundary resulting in a size
> > of 16 for the structure given above. (Yes it's a 32-bit machine.)
> > Don't know the reason for that, since the ABI for i386 does not
> > mention this case explicitly.
> 
> > > Aligment is determined by the granularity of RAM access. E.g. 32-bit
> > > systems tend to have RAM organised as 32-bit words; reading a 32-bit
> > > value which issn't aligned requires reading two adjacent words,
> > > shifting and OR-ing them together to obtain the desired value.
> >
> > Yes, sure, but why would Microsoft's C compiler generate code that
> > results in a fully despensable read operation for the padded word?  (I
> > know this is a Linux programming list, but the question seems related
> > to the overall topic of data alignment in memory.)
> 
> Maybe for binary compatibility with 64-bit systems? There used to be a
> version of NT for Alpha. Also, compared to gcc, MSVC was quite late at
> adopting C99 features, so x86/64 may have been taken into account when
> "long long" was added.

Good point.  Didn't think of that.

> Microsoft tends to pay as much attention to the ABI as the API,
> whereas Unix systems tend to be far less concerned about the ABI. I
> suspect that this is partly because Windows is far less cross-platform
> than Unix, so maintaining a common ABI is a lot less work, and partly
> because of the preference for binary formats on Windows compared to
> textual formats on Unix.

Can't comment on Microsoft's efforts concerning ABI considerations
but, as you indicated, the different peculiarities of ABIs among Unix
systems is definitely a weakness.

Regards

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409

Re: Any pointer to Byte Alignment & Structure Padding?

[Steve Graegert]

On 8/5/05, Amit Dang <amit_dang@intersolutions.stpn.soft.net> wrote:
> I just check /Zp by default is set to 8 not 4 ( which i read some where).
> Moreover all libraries are also compiled with /Zp8. Changing it to some
> other value raises a warning "compiler option 'structure packing (/Zp)'
> inconsistent with precompiled header; current command-line option ignored".

May be /Zp is set to 8 implicitly due to the fact that all libs are
compiled with this option.  While confusing to me, it may be an
explaination for the results I observed.

(Please, let's return to the valuable Linux/Unix discussion)

Regards

	\Steve

--

Steve Graegert <graegerts@gmail.com>
Software Consultancy {C/C++ && Java && .NET}
Mobile: +49 (176)  21248869
Office: +49 (9131) 7126409

Re: Any pointer to Byte Alignment & Structure Padding?

[Glynn Clements]

Steve Graegert wrote:

> > long long is likely to be 8-byte aligned on 64-bit systems and 4-byte
> > aligned on 32-bit systems.
> 
> Agree.  Interestingly, Microsofts VCC (was quite curious, so I did a
> quick test) aligns long long on an 8-byte boundary resulting in a size
> of 16 for the structure given above. (Yes it's a 32-bit machine.) 
> Don't know the reason for that, since the ABI for i386 does not
> mention this case explicitly.

> > Aligment is determined by the granularity of RAM access. E.g. 32-bit
> > systems tend to have RAM organised as 32-bit words; reading a 32-bit
> > value which issn't aligned requires reading two adjacent words,
> > shifting and OR-ing them together to obtain the desired value.
> 
> Yes, sure, but why would Microsoft's C compiler generate code that
> results in a fully despensable read operation for the padded word?  (I
> know this is a Linux programming list, but the question seems related
> to the overall topic of data alignment in memory.)

Maybe for binary compatibility with 64-bit systems? There used to be a
version of NT for Alpha. Also, compared to gcc, MSVC was quite late at
adopting C99 features, so x86/64 may have been taken into account when
"long long" was added.

Microsoft tends to pay as much attention to the ABI as the API,
whereas Unix systems tend to be far less concerned about the ABI. I
suspect that this is partly because Windows is far less cross-platform
than Unix, so maintaining a common ABI is a lot less work, and partly
because of the preference for binary formats on Windows compared to
textual formats on Unix.

-- 
Glynn Clements <glynn@gclements.plus.com>

Re: Any pointer to Byte Alignment & Structure Padding?

[Vadiraj]

On 8/4/05, Steve Graegert <graegerts@gmail.com> wrote:
> On 8/4/05, Vadiraj <vadiraj.cs@gmail.com> wrote:
> > On 8/4/05, Prabhat Hegde <pubs.hegde@gmail.com> wrote:
> 
> [snip]
> 
> > Arranging the structure as mentioned above will definitely remove
> > portablility issue
> > as for both 4 byte or 8 byte aligned compilers the size will be 16 bytes.
> 
> What about endianess?

Portability with respect to alignment. 
-- 
cheers,
Vadi