sizeof and alignement

sizeof and alignement

[David Martinez Garcia]

Dear friends,
We have compiled (using gcc on Linux-Intel platform) with succes some
applications developed in Solaris. Now we want to read the information of
binary files produced in the Sun platform but we have a problem. In
several cases the command 'sizeof' gives different values in both
platforms. Generally only few bytes (4, 8, 12...). We think this is due to
the memory alignment that is forced in the Sun platform. This differences
avoid us to read the right number of bytes when some complex structures
have been writen using the sizeof command in the fwrite instructions.  Is
there any way for solving this problem ? Can we force the gcc compiler to
modify the alignment of the produced code ? Where can we find information
about this common problems when porting applications ?

If you are able of answer any of the previous questions it would be great.
--
David Martinez Garcia
david@fssintl.com
FSS International Europe
Tel. +34 963 826 394
Fax  +34 963 826 392

Re: sizeof and alignement

[Martin v. Loewis]

> Generally only few bytes (4, 8, 12...). We think this is due to the
> memory alignment that is forced in the Sun platform. ... Is there
> any way for solving this problem ?

It's hard to tell whether there is a solution, without seeing the
specific structures in question. For example, your analysis that
memory alignment is the cause could be incorrect, in which case
proposals for solutions would be on the wrong track.

> Can we force the gcc compiler to modify the alignment of the
> produced code ?

To a limited degree, yes; there is a specific __attribute__
declaration for that. Please have a look in the GCC manual, (gcc)Type
Attributes.

> Where can we find information about this common problems when
> porting applications ?

The problem is not as common as you think. Because of the problems,
many people avoid exchanging ad-hoc binary data.

Even if you get sizes and alignment right, you still have to fight
endianness: Sparc is big-endian, Intel little-endian. That means all
the values will be incorrect.

Regards,
Martin

sizeof and alignement

[David Martinez Garcia]

Dear friends,
We have compiled (using gcc on Linux-Intel platform) with succes some
applications developed in Solaris. Now we want to read the information of
binary files produced in the Sun platform but we have a problem. In
several cases the command 'sizeof' gives different values in both
platforms. Generally only few bytes (4, 8, 12...). We think this is due to
the memory alignment that is forced in the Sun platform. This differences
avoid us to read the right number of bytes when some complex structures
have been writen using the sizeof command in the fwrite instructions.  Is
there any way for solving this problem ? Can we force the gcc compiler to
modify the alignment of the produced code ? Where can we find information
about this common problems when porting applications ?

If you are able of answer any of the previous questions it would be great.
--
David Martinez Garcia
david@fssintl.com
FSS International Europe
Tel. +34 963 826 394
Fax  +34 963 826 392

Re: sizeof and alignement

[Martin v. Loewis]

> Generally only few bytes (4, 8, 12...). We think this is due to the
> memory alignment that is forced in the Sun platform. ... Is there
> any way for solving this problem ?

It's hard to tell whether there is a solution, without seeing the
specific structures in question. For example, your analysis that
memory alignment is the cause could be incorrect, in which case
proposals for solutions would be on the wrong track.

> Can we force the gcc compiler to modify the alignment of the
> produced code ?

To a limited degree, yes; there is a specific __attribute__
declaration for that. Please have a look in the GCC manual, (gcc)Type
Attributes.

> Where can we find information about this common problems when
> porting applications ?

The problem is not as common as you think. Because of the problems,
many people avoid exchanging ad-hoc binary data.

Even if you get sizes and alignment right, you still have to fight
endianness: Sparc is big-endian, Intel little-endian. That means all
the values will be incorrect.

Regards,
Martin