Structure member offset.

[gokrix]

#include <stdio.h>
#include <stdlib.h>

struct s
{
int i;
char c;
float f;
};

int main()
{
printf("addr is [%p]. \n", &(((struct s*)0)->c));
return EXIT_SUCCESS;
}

When I compile (gcc -g -W -Wall -ansi -pedantic) and run the above code,
it prints "addr is [0x4].". If I change to 0 to 100, it prints 104.

Why?

Which part of the standard mandates this behaviour?

Thanks,
--GS

[Raghu]

The answer you are getting is correct , becuase in the structure first
element is of integer type , so the "char c " lies 4 bytes away from the
base address you give.
if you interchange position of float f and char c in your structure , the
offset for char c will be 8 from the base address you give.

-Raghu.

"gokrix" <go****@hotmail.com> wrote in message
news:43********@news.beasys.com...

#include <stdio.h>
#include <stdlib.h>

struct s
{
int i;
char c;
float f;
};

int main()
{
printf("addr is [%p]. \n", &(((struct s*)0)->c));
return EXIT_SUCCESS;
}

When I compile (gcc -g -W -Wall -ansi -pedantic) and run the above code,
it prints "addr is [0x4].". If I change to 0 to 100, it prints 104.

Why?

Which part of the standard mandates this behaviour?

Thanks,
--GS

[pemo]

"gokrix" <go****@hotmail.com> wrote in message
news:43********@news.beasys.com...

#include <stdio.h>
#include <stdlib.h>

struct s
{
int i;
char c;
float f;
};

int main()
{
printf("addr is [%p]. \n", &(((struct s*)0)->c));
return EXIT_SUCCESS;
}

When I compile (gcc -g -W -Wall -ansi -pedantic) and run the above code,
it prints "addr is [0x4].". If I change to 0 to 100, it prints 104.

Why?
Which part of the standard mandates this behaviour?

The logic bit ;-)

You're using 0 -or- 100 as an address, and then casting that to struct s
pointer. You then take the address of the member 'c' - which comes after
member 'i'. i is an int, and appears to be 32-bits with your compiler.
32-bits = 4 bytes. So, addresses 0, 1, 2, 3 are 'i', and therefore 'c'
starts at 4.

Presumably, you actually want a struct s, e.g.,

struct s j;

printf("addr is [%p]. \n", &(((struct s*)&j)->c));

[gokrix]

pemo wrote:

"gokrix" <go****@hotmail.com> wrote in message
news:43********@news.beasys.com...

#include <stdio.h>
#include <stdlib.h>

struct s
{
int i;
char c;
float f;
};

int main()
{
printf("addr is [%p]. \n", &(((struct s*)0)->c));
return EXIT_SUCCESS;
}

When I compile (gcc -g -W -Wall -ansi -pedantic) and run the above code,
it prints "addr is [0x4].". If I change to 0 to 100, it prints 104.

Why?

Which part of the standard mandates this behaviour?

The logic bit ;-)

You're using 0 -or- 100 as an address, and then casting that to struct s
pointer. You then take the address of the member 'c' - which comes after
member 'i'. i is an int, and appears to be 32-bits with your compiler.
32-bits = 4 bytes. So, addresses 0, 1, 2, 3 are 'i', and therefore 'c'
starts at 4.

Presumably, you actually want a struct s, e.g.,

struct s j;

printf("addr is [%p]. \n", &(((struct s*)&j)->c));

Maybe I could have framed the question better, along the lines of "Why
is this not an undefined operation?". I was under the impression that
the '->' operation on an address that does not belong to you (say a
random address like 0 or 100) leads to undefined behaviour.

Thanks,
--GS

[pemo]

"gokrix" <go****@hotmail.com> wrote in message
news:43**************@hotmail.com...

pemo wrote:

"gokrix" <go****@hotmail.com> wrote in message
news:43********@news.beasys.com...

<snip>

Maybe I could have framed the question better, along the lines of "Why is
this not an undefined operation?". I was under the impression that the
'->' operation on an address that does not belong to you (say a random
address like 0 or 100) leads to undefined behaviour.

Well, yes it does - unless you know what's at address 0, 100 etc.

Were you expecting a seg fault, or a compiler diagnostic, or something else?

[Eric Sosman]

gokrix wrote:

#include <stdio.h>
#include <stdlib.h>

struct s
{
int i;
char c;
float f;
};

int main()
{
printf("addr is [%p]. \n", &(((struct s*)0)->c));
return EXIT_SUCCESS;
}

When I compile (gcc -g -W -Wall -ansi -pedantic) and run the above code,
it prints "addr is [0x4].". If I change to 0 to 100, it prints 104.

Why?

Which part of the standard mandates this behaviour?

No part of the Standard mandates this behavior.
The behavior is undefined, meaning that the Standard
permits anything at all to happen.

--
Eric Sosman
es*****@acm-dot-org.invalid

[gokrix]

pemo wrote:

"gokrix" <go****@hotmail.com> wrote in message
news:43**************@hotmail.com...

pemo wrote:

"gokrix" <go****@hotmail.com> wrote in message
news:43********@news.beasys.com...

<snip>

Maybe I could have framed the question better, along the lines of "Why is
this not an undefined operation?". I was under the impression that the
'->' operation on an address that does not belong to you (say a random
address like 0 or 100) leads to undefined behaviour.

Well, yes it does - unless you know what's at address 0, 100 etc.

Were you expecting a seg fault, or a compiler diagnostic, or something else?

Yes, indeed.

Thanks,
--GS

[Skarmander]

gokrix wrote:

pemo wrote:

"gokrix" <go****@hotmail.com> wrote in message
news:43**************@hotmail.com...

pemo wrote:

"gokrix" <go****@hotmail.com> wrote in message
news:43********@news.beasys.com...

<snip>

Maybe I could have framed the question better, along the lines of
"Why is this not an undefined operation?". I was under the
impression that the '->' operation on an address that does not belong
to you (say a random address like 0 or 100) leads to undefined
behaviour.

Well, yes it does - unless you know what's at address 0, 100 etc.

Were you expecting a seg fault, or a compiler diagnostic, or something
else?

Yes, indeed.

Valuable lesson, then: undefined behavior can be anything, including doing
something meaningful.

Evaluating &(((struct s*)0)->c) will not cause a segmentation fault because
gcc sees that this expression has a constant value. It doesn't need to
access any memory to compute it, and therefore it won't.

Change it to ((struct s*)0)->c, however, and you will see a quite different
result on most platforms.

Finally, if you want to know the offset of a struct member in a portable
way, use offsetof().

S.

[gokrix]

Eric Sosman wrote:

gokrix wrote:

#include <stdio.h>
#include <stdlib.h>

struct s
{
int i;
char c;
float f;
};

int main()
{
printf("addr is [%p]. \n", &(((struct s*)0)->c));
return EXIT_SUCCESS;
}

When I compile (gcc -g -W -Wall -ansi -pedantic) and run the above
code, it prints "addr is [0x4].". If I change to 0 to 100, it prints
104.

Why?

Which part of the standard mandates this behaviour?

No part of the Standard mandates this behavior.
The behavior is undefined, meaning that the Standard
permits anything at all to happen.

Hmph. I assumed it was ISO C because all three compilers I tried (Sun
C, gcc, MSVC) returned identical results.

Bastard compiler writers. Do they have a union?

Thanks,
--GS

[Thad Smith]

gokrix wrote:

Eric Sosman wrote:

gokrix wrote:

printf("addr is [%p]. \n", &(((struct s*)0)->c));
...
Which part of the standard mandates this behaviour?

No part of the Standard mandates this behavior.
The behavior is undefined, meaning that the Standard
permits anything at all to happen.

Hmph. I assumed it was ISO C because all three compilers I tried (Sun
C, gcc, MSVC) returned identical results.

Getting identical results on 3 compiler/target combinations is a poor
predictor of standard behavior. Forexample, most current processors use
two's complement representation and power-of-two bit length integers,
but code depending on that would not be standard-conforming. Reading
the standard is the best way to determine standard behavior. ;-)

--
Thad

[Richard Tobin]

In article <43******@news.beasys.com>, gokrix <go****@hotmail.com> wrote:

No part of the Standard mandates this behavior.
The behavior is undefined, meaning that the Standard
permits anything at all to happen.

Hmph. I assumed it was ISO C because all three compilers I tried (Sun
C, gcc, MSVC) returned identical results.

Undefined behaviour includes the possibility of doing the obvious,
straightforward thing.

-- Richard