From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fe7dab2193ea2691,start
X-Google-Attributes: gid103376,public
From: pontius@twonky.btv.ibm.com (Dale Pontius)
Subject: Byte sex
Date: 1996/03/28
Message-ID: <4jeuej$mbq@twonky.btv.ibm.com>#1/1
X-Deja-AN: 144735836
distribution: world
organization: IBM Technology Products
reply-to: pontius@vnet.ibm.com
newsgroups: comp.lang.ada
Date: 1996-03-28T00:00:00+00:00
List-Id: <comp.lang.ada>


I've this thing called a 'binary rawspice' file, which has a text
header and a bunch of floating point data. In some variations of
the basic format, there may be more text after the binary data,
and more binary data following that.

At the moment, this file is likely written by an application on
a big-endian machine. (RS/6000 running AIX) I'd like to be able
to read it on both big-endian and little-endian (x86 running OS/2)
machines.

I understand that Streams are the way to go, and I have some code
already running to handle this. In a few more iterations, I'm
about to stumble over reading the floating point data, stored as
either 4-byte or 8-byte REALs.

I suspect I'm going to have to handle the byte-sex issue, and
re-order the bytes as I read them in, in order to get a float
written by big-endian to look civil to a little-endian program.
In Modula-2 I would have declared a variant record, stuffing bytes
in in one order, and pulling the REAL out. The Ada equivalent of
the variant record looks 'safe', (tagged) so that I can't easily
do the same trick. Does Ada include any other facility to help
me here, or do I need to delve into 'Unchecked Conversions'?
(Or is there some 'standard' byte sequence for writing IEEE
 floating point numbers, so that I don't need to worry about it
 at all?)

Thanks,
Dale Pontius
(NOT speaking for IBM)