padding between variables in a structure

[junky_fellow]

Many times the compiler does the padding between two variables
in a structure. For eg. if I have the structure as follows:

struct sample {
int var1;
char var2;
<--- padding of three bytes here
int var3;
}

Why the compiler allocates 3 extra bytes between var2 and var3 ?
I read some articles that say, the compiler always allocates
the address to the variable which is a multiple of the size of
the variable.
for eg. if size of int is 4, the address allocated will always be a
multiple of 4. Why is it so. If the processor can read a
character from any address then why cannot an integer ?

Does all compliers written for a particular architecture generate
the same padding or allocate same space for a particular structure ?

 

[Michael Mair]

Many times the compiler does the padding between two variables
in a structure. For eg. if I have the structure as follows:

struct sample {
int var1;
char var2;
<--- padding of three bytes here
int var3;
}

Why the compiler allocates 3 extra bytes between var2 and var3 ?
I read some articles that say, the compiler always allocates
the address to the variable which is a multiple of the size of
the variable.
for eg. if size of int is 4, the address allocated will always be a
multiple of 4. Why is it so. If the processor can read a
character from any address then why cannot an integer ?

Read FAQ 2.11 to 2.14, then ask again if there are still
questions.

Does all compliers written for a particular architecture generate
the same padding or allocate same space for a particular structure ?

No.

Cheers
Michael

 

[Russell Shaw]

Many times the compiler does the padding between two variables
in a structure. For eg. if I have the structure as follows:

struct sample {
int var1;
char var2;
<--- padding of three bytes here
int var3;
}

Why the compiler allocates 3 extra bytes between var2 and var3 ?
I read some articles that say, the compiler always allocates
the address to the variable which is a multiple of the size of
the variable.
for eg. if size of int is 4, the address allocated will always be a
multiple of 4. Why is it so. If the processor can read a
character from any address then why cannot an integer ?

The address access granularity of a 32bit cpu is usually 4 bytes, because that's
the basic integer size of the cpu. So even chars are commonly placed on 4-byte
boundaries. Multiple chars may be packed into one int location, but that's
implementation-specific iirc.

Does all compliers written for a particular architecture generate
the same padding or allocate same space for a particular structure ?

Probably common, but isn't guaranteed.

 

[Keith Thompson]

The address access granularity of a 32bit cpu is usually 4 bytes,
because that's the basic integer size of the cpu. So even chars are
commonly placed on 4-byte boundaries. Multiple chars may be packed
into one int location, but that's implementation-specific iirc.

On most modern 32-bit systems, the addressing granularity is 1 8-bit
byte. Typically 8-bit objects are 8-bit aligned, 16-bit objects are
16-bit aligned, and 32-bit objects are 32-bit aligned.

This is *all* implementation-specific.

 

[EventHelix.com]

Byte alignment and ordering issues are discussed in the following
article:

http://www.eventhelix.com/RealtimeMantra/ByteAlignmentAndOrdering.htm

Deepa

 

[junky_fellow]

Byte alignment and ordering issues are discussed in the following
article:

http://www.eventhelix.com/RealtimeMantra/ByteAlignmentAndOrdering.htm

Deepa

I had a look at the link suggested by you.
The link says "Structures greater than 16 bytes should be padded
to 16 byte boundary".
Any idea of why this is being done ?

 

[Flash Gordon]

I had a look at the link suggested by you.
The link says "Structures greater than 16 bytes should be padded
to 16 byte boundary".
Any idea of why this is being done ?

That is explained under the heading "Why Restrict Byte Alignment?"

A further point is that some processors will not let you access
non-aligned data.