Mandalika's scratchpad [ Work blog @Oracle | My Music Compositions ]

Old Posts: 09.04  10.04  11.04  12.04  01.05  02.05  03.05  04.05  05.05  06.05  07.05  08.05  09.05  10.05  11.05  12.05  01.06  02.06  03.06  04.06  05.06  06.06  07.06  08.06  09.06  10.06  11.06  12.06  01.07  02.07  03.07  04.07  05.07  06.07  08.07  09.07  10.07  11.07  12.07  01.08  02.08  03.08  04.08  05.08  06.08  07.08  08.08  09.08  10.08  11.08  12.08  01.09  02.09  03.09  04.09  05.09  06.09  07.09  08.09  09.09  10.09  11.09  12.09  01.10  02.10  03.10  04.10  05.10  06.10  07.10  08.10  09.10  10.10  11.10  12.10  01.11  02.11  03.11  04.11  05.11  07.11  08.11  09.11  10.11  11.11  12.11  01.12  02.12  03.12  04.12  05.12  06.12  07.12  08.12  09.12  10.12  11.12  12.12  01.13  02.13  03.13  04.13  05.13  06.13  07.13  08.13  09.13  10.13  11.13  12.13  01.14  02.14  03.14  04.14  05.14  06.14  07.14  09.14  10.14  11.14  12.14  01.15  02.15  03.15  04.15  06.15  09.15  12.15  01.16  03.16  04.16  05.16  06.16  07.16  08.16  09.16  12.16  01.17  02.17  03.17  04.17  06.17  07.17  08.17  09.17  10.17  12.17  01.18  02.18  03.18  04.18  05.18  06.18  07.18  08.18  09.18  11.18  12.18  01.19  02.19  05.19  06.19  08.19  10.19  11.19  05.20  10.20  11.20  12.20  09.21  11.21  12.22 


Wednesday, October 13, 2004
 
Sun C/C++: #pragma pack

Let's have a look at the following program and the output

bpte4500s001:/sunbuild1/giri/testcases/%cat aligndata.c
#include <stdio.h>

typedef struct user {
char name[10];
int age;
float salary;
} usr;

int main()
{
printf("\n ** sizeof(char) = %d, sizeof(int) = %d, sizeof(float) = %d\n ** sizeof(struct user) = %d\n", sizeof(char), sizeof(int), sizeof(float), sizeof(struct user));

return (0);
}

bpte4500s001:/sunbuild1/giri/testcases/%./a.out
** sizeof(char) = 1, sizeof(int) = 4, sizeof(float) = 4
** sizeof(struct user) = 20
sizeof(struct user) is supposed to return 18, but returned 20. What's wrong with the compiler - is it a bug?

-NO- it is not a bug. Sun Studio compiler(s) generate 32-bit code, and in that mode there is a significant run-time performance penalty for unaligned accesses, like accessing a 32-bit int which isn't aligned on a 32-bit dword boundary. To produce faster code, Sun Studio compiler(s) pads struct members so that each one can be accessed without delays; this sometimes produces struct size which is larger than the sum of the sizes of its members

If this is not the desired behavior and if we don't want to get the structure padded, we can let compiler know the same by using a compiler directive (aka pragma) called "pack". Syntax of pragma pack:
#pragma pack(n)
n must be 0 or a power of 2. A value of other than 0 instructs the compiler to use the smaller of n-byte alignment and the platform's natural alignment for the data type. A value of 1 instructs the compiler not to perform any alignment. When n is 0 or omitted, the member alignment reverts to the natural alignment values.

If the value of n is the same as or greater than the strictest alignment on the platform, the directive has the effect of natural alignment

A pack directive applies to all structure definitions which follow it, until the next pack directive.

Lets include the pragma 'pack' in our source and run the program

bpte4500s001:/sunbuild1/giri/testcases/%cat aligndata.c
#include <stdio.h>

#pragma pack(1)

typedef struct user {
char name[10];
int age;
float salary;
} usr;

int main()
{
printf("\n ** sizeof(char) = %d, sizeof(int) = %d, sizeof(float) = %d\n ** sizeof(struct user) = %d\n", sizeof(char), sizeof(int), sizeof(float), sizeof(struct user));

return (0);
}
bpte4500s001:/sunbuild1/giri/testcases/%./a.out
** sizeof(char) = 1, sizeof(int) = 4, sizeof(float) = 4
** sizeof(struct user) = 18
Note:
When using #pragma pack on a SPARC platform to pack denser than the type's default alignment, the -misalign option must be specified for both the compilation and the linking of the application

Reference:
Sun Studio 9 C++ user's guide

Acknowledgements:
Dheeraj (aka tw|lit), Naresh Shroff



Comments: Post a Comment



<< Home


2004-2019 

This page is powered by Blogger. Isn't yours?