trretretre

Ordinarily you shouldn't care how the compiler organizes variables, because it will be architecture-specific.

My computer: Linux wolverine 2.6.13-15.12-default #1 Thu Aug 24 11:23:58 UTC 2006 i686 athlon i386 GNU/Linux

Your example program reports:

Sizeof cool is 8

Sizeof cool3 is 20

Sizeof cool2 is 0

Sizeof cool4 is 2
address of cool is bfa5e1a0
address of cool3 is bfa5e18c
address of cool2 is bfa5e18c
address of cool4 is bfa5e18a

&heh1 is bfa5e184

I don't get why it matters. Ken's answer is right on. Each implementation is free to park those variables wherever it wants.

What problem are you trying to solve?

Hi all!

I agree with ken and jim that the addresses assigned will be architecture specific. and the addresses shown on ur machine are easily justified as well. but the values which I see on my machine are not.

U can see below that the difference between address of cool3 and cool2 is 0x10 bytes(16 bytes) where as size of cool3 is 20 bytes?
and why is there a gap of 40 bytes in cool and cool3 address? i mean even if we consider memory alignment, padding etc, i couldnt find out the reason for so much gap. i mean this gap wont be used by anything at all. so is it that that memory is being wasted?


Regards,
Shivali

What are &heh1 and &heh2?

heh1 and heh2 are just two pointer vaiables. &heh1 is address of that pointer variable(heh1). i m pasting their address also below now:

#include <stdio.h>

struct heh
{
long* ptr;
char data[0];
};

void hello()
{
double cool;
char cool3[20];
char cool2[0];
char cool4[2];
struct heh* heh1, heh2;

printf("\nSizeof cool is %d \n", sizeof(cool));
printf("\nSizeof cool3 is %d \n", sizeof(cool3));
printf("\nSizeof cool2 is %d \n", sizeof(cool2));
printf("\nSizeof cool4 is %d \n", sizeof(cool4));

printf("address of cool is %x\n", &cool);
printf("address of cool3 is %x\n", &cool3);
printf("address of cool2 is %x\n", &cool2);
printf("address of cool4 is %x\n", &cool4);

printf("\n&heh1 is %x ", &heh1);
printf("\n&heh2 is %x ", &heh2);
}

int main()
{
hello();
return 0;
}


Output:
=======


Sizeof cool is 8

Sizeof cool3 is 20

Sizeof cool2 is 0

Sizeof cool4 is 2
address of cool is bfffbd28
address of cool3 is bfffbd00
address of cool2 is bfffbcf0
address of cool4 is bfffbcee

&heh1 is bfffbce8
&heh2 is bfffbcd0

hi
try to compile your code with cc -S which will give u
assembly code

then open it with vi editor to see assembly code for your machine

try to analyse it

bye

On what kind of system are you running your test program?
If "uname" is available, what does "uname -a" tell you ?
What options are you giving the C compiler to compile and build?

The same thing happens to me:

or

&cool == X+88
&cool3 == X+48
&cool2 == X+32
&cool4 == X+30
&heh1 == X+24
&heh2 == X

which is what shivaligupta had. That is, the memory layout is:

• heh2 (4 bytes)
• 20 unused bytes
• heh1 (4 bytes)
• 2 unused bytes
• cool4 (2 bytes)
• cool2 (0 bytes)
• 16 unused bytes
• cool3 (20 bytes)
• 20 unused bytes
• cool (8 bytes)

This is with GCC 3.3.5.

shivaligupta -

That's definitely a dumb question. Your time would be *much* better spent reading a book on compilers, than counting byte offsets in random variable declarations.

If you insist, however: please:
a) follow varun_shrivastava's advise, and try to interpret the assembler output
b) analyze the organization of the entire (elf?) format executable
c) speculate on why data in the file is organized the way it it

PS:
I think that's the first time I've ever seen variables named after "Beavis and Butthead" expressions. Oh well...

paulsm4
I hav obviously read books on compilers and thats why I asked this question. Still Cudnt find the answer so thought posting it on this forum may help but forgot that some ppl prefer reading books than trying something. Thanks for your suggetsions.