Also be very carefull with structures sent over the network, even if the types in the structure do not have problems with byte ordering (like floating points).
You can NEVER send structures in binary format because compilers often add byte padding to guarantee arrays of structures will be alligned properly (space / time tradoff), thus the exact same structure on two different platforms could be even a different size. Even the same processor architecture, but different compiler. Here is my favorite example:
struct mystruct
{
char c;
double d;
};
If you do a sizeof(mystruct), depending on the platform and compiler, you will get either 9, 12, or 16 bytes.
In the case of 9, the compiler packs the structure as small as possible, then copies the double to an alligned memory space before accessing it, in the case of 12, doubles must be alligned on a 4 byte boudry (x86) and the compiler uses byte padding to guarantee that arrays of structures are all properly alligned, in the case of 16, doubles must be alligned on an 8 byte boundry (Sparc) and the compiler uses byte padding.
On 10/22/06, arm.user <> wrote:
Dear Joe,
Thanks for your helpful reply. As it happens, the application
involves communications with an x86-based platform, so your points
(5) & (6) are important.
Interestly, a long long int (8 bytes) is stored on the ARM in little
endian format, i.e., no expected 32-bit strangeness.
I guess that DWORD swapping is the way to go in the first instance.
Thanks again,
Roy
--- In ts-7000%40yahoogroups.com, Joe Bouchard <> wrote:
>
> On Sat, Oct 21, 2006 at 12:30:47PM -0000, arm.user wrote:
> > Hi All,
> >
> > While porting an x86-based communications project to a TS-7250,
I
> > encountered an bug relating to how (8-byte) doubles are stored
> > internally in applications compiled using arm-linux-gcc-3.3.4.
> >
> > The bug manifests itself as a non-standard byte ordering in
memory.
> > Specifically, instead of the 8-bytes bytes associated with
double
> > precision float being ordered as:
> >
> > B0 B1 B2 B3 B4 B5 B6 B7
> >
> > they are actually ordered as:
> >
> > B4 B5 B6 B7 B0 B1 B2 B3
> >
> > which is neither LSB or MSB. The bytes, when re-arranged, do
> > correspond to the IEEE-754 format and yield correct floating
point
> > value.
> >
> > A note about this bug appear this appears
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18620, where the
issue
> > declared "WONTFIX".
> >
> > Regards
> > Roy
>
> It's important to ask "what does this mean in the real world?",
and I'm not able
> to translate the implications of the above statements. I will
make a few
> statements and hopefully you can tell me which ones are wrong...
>
> 1) Performing traditional mathematical operations should work
fine, as the
> compiler knows what it is doing in a consistant manner.
>
> 2) It does not matter whether the code is compiled on the ARM or
cross-compiled
> on an x86, the behavior is consistant.
>
> 3) the following should work OK: printf("value is %d",double),
again because the
> compiler is familiar with what it is doing.
>
> 4) If I open an ASCII text file for output, and write records
which include
> double using fprintf, everything will work fine. I tend to do
this anyway.
>
> 5) If I open a binary file for output, and write records which
include doubles,
> and then try to read those files later on on an x86 or PowerPC
system, I will
> not get the results I had hoped for.
>
> 6) If I have a double in memory, and then take that pointer and
cast it to
> (void *) and start manipulating the bytes directly, I will
definitely run
> into troubles if I use the same algorithm used on x86 or
powerPC.
>
> 7) The above failures (5) and (6) are valid concerns, but they
would also be a
> problem when you are switching between x86 and powerPC, or
possibly any of
> the 11 platforms supported by Debian at this time. That's just
good old
> fashioned binary incompatibility.
>
> 8) The workaround described in bugzilla is probably in place much
of the time,
> even if we aren't even aware of it. When I'm doing cross
compiles I believe
> I normally see -mcpu=arm9 or -mcpu=arm9tdmi flying by, and if
so, the
> workaround is in place, although it's not clear to me what
difference this
> makes.
>
> Thanks,
> Joe
>
-- Dr. Don W. Carr J. G. Montenegro 2258 Guadalajara, Mexico +52-333-630-0704 +52-333-836-4500 ext 2930
__._,_.___
![]()
SPONSORED LINKS
__,_._,___
|