Last stream problem: byte order

Last stream problem: byte order

[Erik Sigra]

Now my stream application almost works. The last remaining problem seems to 
be byte order. The server is programmed in C++ with Qt and the client is 
programmed in Ada with adasockets-1.0. The last thing I did was to change the 
byte order in the server 
("the_stream.setByteOrder(QDataStream::LittleEndian);"). After that the 
numbers came out right at the other end.

However, this may not be a safe solution. The safe way would probably be to 
always have the network communication in BigEndian format and make sure the 
client always obeys this, regardless of the platform.

So how does one set the byte order to BigEndian on the Ada side? Or is there 
a different, better idea?

Re: Last stream problem: byte order

[Jeffrey Carter]

Erik Sigra wrote:
> 
> Now my stream application almost works. The last remaining problem seems to
> be byte order. The server is programmed in C++ with Qt and the client is
> programmed in Ada with adasockets-1.0. The last thing I did was to change the
> byte order in the server
> ("the_stream.setByteOrder(QDataStream::LittleEndian);"). After that the
> numbers came out right at the other end.
> 
> However, this may not be a safe solution. The safe way would probably be to
> always have the network communication in BigEndian format and make sure the
> client always obeys this, regardless of the platform.
> 
> So how does one set the byte order to BigEndian on the Ada side? Or is there
> a different, better idea?

If you want your code to deal with things with a specific byte order
regardless of the platform, you'll need to read individual bytes and put
them together properly, and decompose things into bytes and write them
in the appropriate order.

Since this requires explicit processing in your Ada code, it doesn't
really matter which endianness you choose, as long as everything uses
the same endianness.

-- 
Jeffrey Carter

Re: Last stream problem: byte order

[Stephen Leake]

Erik Sigra <sigra@home.se> writes:

> Now my stream application almost works. The last remaining problem
> seems to be byte order. The server is programmed in C++ with Qt and
> the client is programmed in Ada with adasockets-1.0. The last thing
> I did was to change the byte order in the server
> ("the_stream.setByteOrder(QDataStream::LittleEndian);"). After that
> the numbers came out right at the other end.
> 
> However, this may not be a safe solution. The safe way would probably be to 
> always have the network communication in BigEndian format and make sure the 
> client always obeys this, regardless of the platform.
> 
> So how does one set the byte order to BigEndian on the Ada side? 

By writing code that does it :). There is a package Word_Order_Convert
in SAL at http://users.erols.com/leakstan/Stephe/Ada/sal.html

Note that's _word_ order convert; you'll need _byte_ order convert.
Should be easy to change. I was working with 1553 buses, which are all
16 bit words.

> Or is there a different, better idea?

You can use a higher layer communications package, that does byte
swapping for you. There is one called XDR in the GNAT GLADE
distributed annex package.

-- 
-- Stephe

Re: Last stream problem: byte order

[Eric G. Miller]

In <mailman.1017085322.10332.comp.lang.ada@ada.eu.org>, Erik Sigra wrote:

> Now my stream application almost works. The last remaining problem seems to 
> be byte order. The server is programmed in C++ with Qt and the client is 
> programmed in Ada with adasockets-1.0. The last thing I did was to change the 
> byte order in the server 
> ("the_stream.setByteOrder(QDataStream::LittleEndian);"). After that the 
> numbers came out right at the other end.
> 
> However, this may not be a safe solution. The safe way would probably be to 
> always have the network communication in BigEndian format and make sure the 
> client always obeys this, regardless of the platform.
> 
> So how does one set the byte order to BigEndian on the Ada side? Or is there 
> a different, better idea?

Up to you to decide when and what order, but the following type of thing
could be used by read/write routines...

with Ada.Unchecked_Conversion;
package  Byte_Swap is

	type Bits8  is mod 2**8;

	type Two_Byte is 
	   record
	      A : Bits8;
	      B : Bits8;
	   end record;

	for Two_Byte use
	   record
	      A at 0*2 range 0 .. 7;
	      B at 0*2 range 8 .. 15;
	   end record;

        function To_Two_Byte is new
		Ada.Unchecked_Conversion (Source => Short_Integer,
		                          Target => Two_Byte);
        function To_Short is new
 		Ada.Unchecked_Conversion (Source => Two_Byte,
                                          Target => Short_Integer);
-- etc ...

        procedure Swap (data : in out Two_Byte);

-- etc ...

package body Swap_Bytes is

        procedure Swap (data : in out Two_Byte) is
		tmp : Bits8;
	begin
		tmp    := data.A;
	        data.A := data.B;
                data.B := tmp;
	end Swap;

-- etc ...

Re: Last stream problem: byte order

[Dr. Michael Paus]

Erik Sigra schrieb:
> 
> Now my stream application almost works. The last remaining problem seems to
> be byte order. The server is programmed in C++ with Qt and the client is
> programmed in Ada with adasockets-1.0. The last thing I did was to change the
> byte order in the server
> ("the_stream.setByteOrder(QDataStream::LittleEndian);"). After that the
> numbers came out right at the other end.
> 
> However, this may not be a safe solution. The safe way would probably be to
> always have the network communication in BigEndian format and make sure the
> client always obeys this, regardless of the platform.
> 
> So how does one set the byte order to BigEndian on the Ada side? Or is there
> a different, better idea?

The easiest way to solve this problem once an forever is to manipulate the
file s-stratt.adb from the GNAT library. It handles all the stream stuff for
primitive types like integers, floats etc. If you just introduce a procedure
which swaps the bytes for each type you can achieve the effect you want.
I did that a long time ago, so my implementation is currently outdated but
if you like I could send you a copy. If you also check the byte order of your
system at runtime (there is a system constant in Ada which you can check) you
can even achieve the effect that all stream data is always written in network
byte order independent of the platform your program is running on. This makes
it easy, e.g. to exchange data with a Java application which writes its data
to a DataOutputStream.

Michael

Re: Last stream problem: byte order

[Pascal Obry]

"Dr. Michael Paus" <paus@ib-paus.com> writes:

> The easiest way to solve this problem once an forever is to manipulate the
> file s-stratt.adb from the GNAT library. It handles all the stream stuff for

No the /easiest/ way to do that is to grab the GLADE s-stratt.adb
implementation :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Last stream problem: byte order

[Dr. Michael Paus]

Pascal Obry wrote:
> 
> "Dr. Michael Paus" <paus@ib-paus.com> writes:
> 
> > The easiest way to solve this problem once an forever is to manipulate the
> > file s-stratt.adb from the GNAT library. It handles all the stream stuff for
> 
> No the /easiest/ way to do that is to grab the GLADE s-stratt.adb
> implementation :)

Please correct me if I am wrong but as far as I remember the data produced by
this implementation is not compatibel with other languages like, e.g. Java.
It uses an XDR encoding for the data which was invented by SUN in the late 80s
for their RPC stuff but does not seem to be used in more recent designs like, e.g.
Java. It also produces a significant overhead compared to a solution which just
swaps some bytes. I also wonder how the original poster would get this XDR
encoding into his C++ framework. (I don't say it's not possible. It's just a
question whether it's worth the effort).

I have made my solution available on http://www.ib-paus.com/downloads . If you
like you can have a look at it.

Michael

Re: Last stream problem: byte order

[Pascal Obry]

"Dr. Michael Paus" <paus@ib-paus.com> writes:

> Please correct me if I am wrong but as far as I remember the data produced by
> this implementation is not compatibel with other languages like, e.g. Java.
> It uses an XDR encoding for the data which was invented by SUN in the late
> 80s for their RPC stuff but does not seem to be used in more recent designs

Right it is an XDR encoding.

> like, e.g. Java. It also produces a significant overhead compared to a
> solution which just swaps some bytes.

Agreed.

> I also wonder how the original poster would get this XDR
> encoding into his C++ framework. (I don't say it's not possible. It's just a
> question whether it's worth the effort).

Don't know.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Last stream problem: byte order

[Erik Sigra]

tisdagen den 26 mars 2002 11.25 skrev du:
> If you also check the byte order of your system at runtime (there is a
> system constant in Ada which you can check) you can even achieve the effect
> that all stream data is always written in network byte order independent of
> the platform your program is running on.

Why runtime check? Compile time check seems more reasonable to me. Or can the 
same compiled program really run on architectures with different endiannes?

Re: Last stream problem: byte order

[Dr. Michael Paus]

Erik Sigra schrieb:
> 
> tisdagen den 26 mars 2002 11.25 skrev du:
> > If you also check the byte order of your system at runtime (there is a
> > system constant in Ada which you can check) you can even achieve the effect
> > that all stream data is always written in network byte order independent of
> > the platform your program is running on.
> 
> Why runtime check? Compile time check seems more reasonable to me. Or can the
> same compiled program really run on architectures with different endiannes?

It depends on how clever the compiler is. If the compiler optimizes the
static expression in the following if-statement away then it is indeed a
compile time check. Otherwise it is a run-time check.

      if System.Default_Bit_Order = System.Low_Order_First then
         ... (swap the bytes)
      else
         ... (don't swap the bytes)
      end if;

But I don't think this makes a big difference in either case.

Michael

Re: Last stream problem: byte order

[Eric G. Miller]

In <3CA20BAA.FD53C08A@ib-paus.com>, Dr. Michael Paus wrote:

> Erik Sigra schrieb:
>> 
>> tisdagen den 26 mars 2002 11.25 skrev du:
>> > If you also check the byte order of your system at runtime (there is a
>> > system constant in Ada which you can check) you can even achieve the effect
>> > that all stream data is always written in network byte order independent of
>> > the platform your program is running on.
>> 
>> Why runtime check? Compile time check seems more reasonable to me. Or can the
>> same compiled program really run on architectures with different endiannes?
> 
> It depends on how clever the compiler is. If the compiler optimizes the
> static expression in the following if-statement away then it is indeed a
> compile time check. Otherwise it is a run-time check.
> 
>       if System.Default_Bit_Order = System.Low_Order_First then
>          ... (swap the bytes)
>       else
>          ... (don't swap the bytes)
>       end if;
> 
> But I don't think this makes a big difference in either case.

GNAT gives a warning that the condition is always true (or false).  Don't know
if it eliminates the unreachable branch (I would think so with -02).  Resorting
to preprocessing trickery would probably insure it is always a compile time
check.  Don't know if there's another way...

Re: Last stream problem: byte order

[Stephen Leake]

"Eric G. Miller" <egm2@jps-nospam.net> writes:

> > It depends on how clever the compiler is. If the compiler optimizes the
> > static expression in the following if-statement away then it is indeed a
> > compile time check. Otherwise it is a run-time check.
> > 
> >       if System.Default_Bit_Order = System.Low_Order_First then
> >          ... (swap the bytes)
> >       else
> >          ... (don't swap the bytes)
> >       end if;
> > 
> > But I don't think this makes a big difference in either case.
> 
> GNAT gives a warning that the condition is always true (or false).
> Don't know if it eliminates the unreachable branch (I would think so
> with -02). Resorting to preprocessing trickery would probably insure
> it is always a compile time check. Don't know if there's another
> way...

You can have two package bodies, one for Low_Order_First, one for
High_Order_First. Choose which body you use at compile time by setting
paths (in gnat, this is done in gnat.adc via pragma Source_Name).

-- 
-- Stephe

Re: Last stream problem: byte order

[Simon Wright]

"Eric G. Miller" <egm2@jps-nospam.net> writes:

> In <3CA20BAA.FD53C08A@ib-paus.com>, Dr. Michael Paus wrote:

> >       if System.Default_Bit_Order = System.Low_Order_First then
> >          ... (swap the bytes)
> >       else
> >          ... (don't swap the bytes)
> >       end if;
> > 
> > But I don't think this makes a big difference in either case.
> 
> GNAT gives a warning that the condition is always true (or false).
> Don't know if it eliminates the unreachable branch (I would think so
> with -02).  Resorting to preprocessing trickery would probably
> insure it is always a compile time check.  Don't know if there's
> another way...

I've just tried a similar code with 3.13p, 3,14a1 and 3.15a and none
of them flagged a warning here .. with or without -O2.

You can use -gnatG to see the tree from which code is generated.

Re: Last stream problem: byte order

[Eric G. Miller]

In <x7v663gczbb.fsf@smaug.pushface.org>, Simon Wright wrote:

> "Eric G. Miller" <egm2@jps-nospam.net> writes:
> 
>> In <3CA20BAA.FD53C08A@ib-paus.com>, Dr. Michael Paus wrote:
> 
>> >       if System.Default_Bit_Order = System.Low_Order_First then
>> >          ... (swap the bytes)
>> >       else
>> >          ... (don't swap the bytes)
>> >       end if;
>> > 
>> > But I don't think this makes a big difference in either case.
>> 
>> GNAT gives a warning that the condition is always true (or false).
>> Don't know if it eliminates the unreachable branch (I would think so
>> with -02).  Resorting to preprocessing trickery would probably
>> insure it is always a compile time check.  Don't know if there's
>> another way...
> 
> I've just tried a similar code with 3.13p, 3,14a1 and 3.15a and none
> of them flagged a warning here .. with or without -O2.

gnatmake -g -gnatwa <foo>

Guess I forget to mention "if you turn on warnings...".

Re: Last stream problem: byte order

[Simon Wright]

"Eric G. Miller" <egm2@jps-nospam.net> writes:

> > I've just tried a similar code with 3.13p, 3,14a1 and 3.15a and none
> > of them flagged a warning here .. with or without -O2.
> 
> gnatmake -g -gnatwa <foo>
> 
> Guess I forget to mention "if you turn on warnings...".

Well, I did know that -- turns out that the installation on the laptop
doesn't generate the warnings, the main box does. I thought the laptop
had a straight copy of the version built on the main box .. ho hum,
always something to keep one on the ball ..

Re: Last stream problem: byte order

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> "Eric G. Miller" <egm2@jps-nospam.net> writes:
> 
> > > I've just tried a similar code with 3.13p, 3,14a1 and 3.15a and none
> > > of them flagged a warning here .. with or without -O2.
> > 
> > gnatmake -g -gnatwa <foo>
> > 
> > Guess I forget to mention "if you turn on warnings...".
> 
> Well, I did know that -- turns out that the installation on the laptop
> doesn't generate the warnings, the main box does. I thought the laptop
> had a straight copy of the version built on the main box .. ho hum,
> always something to keep one on the ball ..

Turned out the laptop was invoking 3.14a1; I guess 3.14p gives the
warning (3.15a certainly does).

Sorry for the confusion.