Structure size on VAX and ALPHA

[ram_47]

Hi,

typedef struct {
unsigned char length;
unsigned char l2;
char name[8];
int num;
} l_s_r;

I have the above declaration in a header file. and when i print the size of this structure


printf("Size of structure l_s_r is : %d",sizeof(l_s_r));


i get 2 different values on ALPHA and VAX-
On ALPHA the size is shown as - 16 bytes
ON VAX the size is shown as - 14 bytes


Interestingly the size of the below datatypes are same on both ALPHA and VAX.
unsigned char size is '1' byte
char size is '1' byte
int size is '4' byte


Then what could be reason for the difference in size of structure?

[Volker Halle]

Ram,

alignment ?!

On Alpha, that int num will probably be naturally aligned, i.e. aligned to the next longword address.

Volker.

[Marc Van den Broeck · Accepted solution]

Ram,

look at qualifier member_alignment for the c-compiler.
You can try to compile with /nomember_ali and look at the effect.

Rgds
Marc

[ram_47]

Volker,

I did not really get what you are saying. Could you pl elaborate? Also, what is the solution to overcome this problem, because instead of reading 14 bytes my structure is reading 16 bytes and so my file pointer is positioned at a wrong place.

[Robert Gezelter]

ram,

I agree with Volker. The alignment default in your two systems is different. Technically, to ensure that alignment is one way or the other, you need to use the #pragma [no]member_alignment C/C++ compiler directive.

Typically, this #pragma is used with state save/restore code, as follows:

#pragma member_alignment __save
#pragma [no]member_alignment

{ code defining structures }

#pragma member_alignment __restore

You need to save/restore the current settings because different source sets may have differing presumptions, for a wide variety of reasons. Saving/restoring the member_alignment state allows your structure to be defined as needed, without impacting the rest of the compilation.

For example, message formats for network messages are often packed by bytes, and use the nomember_alignment attribute. In memory data structures want the efficiency, and thus use the member_alignment attribute.

- Bob Gezelter, http://www.rlgsc.com

[Volker Halle]

Ram,

Marc seems to have answered this question already.

Please note that your code may pay a performance penalty, if you access data at non-aligned addresses. Sometimes the compiler can handle this, but sometimes it also happens at runtime, which is bad for performance on Alpha and really bad on Itanium (this is called alignment faults).

Volker.

[John Gillings]

ram,

Alpha and Itanium compilers will add padding bytes to structure members in order to align them on "natural" boundaries. So, your structure has 2 single characters, followed by an 8 character string. That's 10 bytes. The compiler adds 2 bytes of padding so the integer starts on a longword boundary (multiple of 4).

The VAX compiler does not align structure members by default.

So you have a choice if you want the VAX and Alpha compilers to both lay out your structure in memory identically. You can:

1) force the compiler to omit the pad bytes and place the members exactly where you want them - this can be specified with a qualifier "/NOMEMBER_ALIGNMENT" to affect ALL structures, or selectively with a pragma "#pragma member_alignment".

2) rearrange your fields so they will be aligned without having to pad anything

3) add your own padding

Accesses to unaligned data is more expensive than accessing aligned data on all three architectures. It's moderate on VAX, bad on Alpha and VERY bad on Itanium.

Bob and Marc have suggested option 1, but you may be better off rearranging the fields to:

typedef struct {
int num;
unsigned char length;
unsigned char l2;
char name[8];
} l_s_r;

So, the int is naturally aligned with no need for padding. General rule is to declare quads, followed by longs, followed by short ints, then character strings. Remember that for most code the order of fields and extra padding shouldn't matter (some, myself included, would argue that code that does depend on field order is fundamentally broken and should be fixed!)

If you're somehow stuck with a misaligned record in a data file, I recommend defining two structures - the on disk structure and the in-memory structure. Hide the misaligned structure in your file access layer and move the fields into the aligned structure for processing. Even better, write a program to convert all your files into an aligned structure layout.

[ram_47]

John,

2 observations -

1- rearranging the fields within the structure still returns me the wrong struct size. (returns me 16 bytes)

2- enclosing the structure between the #pragma directive works! (returns me 14 bytes)