Re: Endian problems - what best way to solve it with least effort

[Simon Wright <simon@pushface.org>]

Anh Vo <anhvofrcaus@gmail.com> writes:

> I have an application previously running on Big Endian machine
> communicating with a client simulator through socket. This client is
> coded in Java running on a separate machine. The data exchanged
> between them have different structures down to bits and bytes.
>
> Currently, this application is being ported to GNAT running on RH 5.4
> (Little Endian PC machine). As the result, both application and client
> do not communicate correctly any longer due to endian mismatched. The
> reason is that Java VM uses Big Endian format even though the client
> runs on a PC.

Was the previous version in Ada? I presume so or you'd have a
translation effort with would already be non-minimal.

What was the previous code like? A sample from a shortish message would
help! 

If it just used Streams there might be a simple approach; in the Ada RTS
adainclude/ there's a file s-stratt-xdr.adb (possibly s-strxdr.adb),
which does stream formatting in network (b-e) order as you require.

You should be able to put a copy of this file in your Ada source path as
s-stratt.adb and recompile with the -a flag to gnatmake.

I'm not sure whether gprbuild supports -a.

Don't use the -f flag unless you want to rebuild the whole RTS!