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

[Anh Vo <anhvofrcaus@gmail.com>]

On Tuesday, March 13, 2012 11:35:34 AM UTC-7, Simon Wright wrote:
> 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!

Thank you all very much for your reply. 

Our team has decided to modify Java side due to less effort is involved. In addition, the Little Endian conversion utility is used. I will update the result once it is completely tested.