Compiler issue?

[MimiMi]

If a struct with the same name are defined in two different files,
something is wrong when building since the wrong struct definition is used when accessing via pointer.

See the following example:
-----------------------------------------------------------------
File A:
typedef struct
{
uint8 a;
uint16 b;
} MyStruct_t;

int FuncA(void)
{
MyStruct_t ObjA = {2, 3};
MyStruct_t *PtrA = &ObjA;

printf("Offset of element b in ObjA = %i\n", &ObjA - &ObjA.b);
printf("Offset of element b in PtrA = %i\n", PtrA - &PtrA->b);
}

--------------------------------
File B:

typedef struct
{
uint8 a;
uint32 b;
} MyStruct_t;

int FuncB(void)
{
...
}
----------------------------------
In the example FuncA will display, "Offset of element b in ObjA = 2" and "Offset of element b in PtrA = 4". The difference being due to element b being treated as a uint32 when accessed via a pointer changing the alignment in the structure.

Does anyone know what is causing this error? Is it a compiler issue? If so, is it a known issue?
I'm using Visual C++ Express 2005 compiler with service pack 1.

Thank you!

[gpraghuram]

I think it should be 4 in both cases as (32 bit)compiler takes 4 byts alignment.

raghu

[JosAH]

What happens if you cast all addresses to char* first and then do the subtraction?

kind regards,

Jos

ps. The struct definition in file B isn't in scope at all.

[weaknessforcats]

There's no compiler issue.

Each implementation file is compiled separately. Therefore you can have a MyStruct_t in every file with completely definitions. However, when all these different definitions reach the linker who requires variable and function names to be unique, your build terminates with redefinition errors.

[vmpstr]

That code doesn't even quite compile for me.

Putting various brackets and casting to int reveals that the answer is -2 for both (for me). Are you sure that you are getting 2 and 4? I mean I would think that the answer would be negative?

Try using %p instead of %i in the printf statements.

[MimiMi]

Thank you all for your input!

[JosAH]

There's no compiler issue.

As a matter of fact there is, but it's another issue: when you do x-y for two
pointers x and y to different types (and different sizes!) it is an error. That's
why I asked to cast both pointers to a char*.

kind regards,

Jos

[MimiMi]

So, is the fault "mine", ie you're not supposed to write code that way, or is it Microsoft (Visual C++ Express 2005 linker)?

[JosAH]

So, is the fault "mine", ie you're not supposed to write code that way, or is it Microsoft (Visual C++ Express 2005 linker)?

I'd say: both; pointer arithmetic (x-y) doesn't yield a result when x and y are pointers
to different types but your compiler should've warned you about it. Your linker
is innocent in this particular case. ;-)

kind regards,

Jos

edit: this is what the C99 Standard has to say about it:

79)Another way to approach pointer arithmetic is first to
convert the pointer(s) to character pointer(s): In this
scheme the integer expression added to or subtracted from
the converted pointer is first multiplied by the size of
the object originally pointed to, and the resulting
pointer is converted back to the original type. For
pointer subtraction, the result of the difference between
the character pointers is similarly divided by the size
of the object originally pointed to.

[MimiMi]

I should have added that if PtrA->b is read in FuncA the 4 bytes beyond the end of the structure are accessed rather than the expected value; 3. ObjA.b does return the correct value...

Does anyone know why?

[MimiMi]

I have now found the answer to my question! The issues I had are well explained here:
Working with Packing Structures

I didn't know about this before.. Well, I knew data alignment and stuff, what I mean is that I didn't know about the compiler ways to "specify" it. It's always nice to learn new stuff!
Cheers!

[donbock]

@MimiMi
#pragmas are not portable. You should consider whether there's a way to accomplish your goals without tying your source code to a particular compiler implementation. If you do rely on nonportable behavior, at least document your assumptions carefully and clearly identify at least one compiler that is acceptable.