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=1.2 required=5.0 tests=BAYES_00,FROM_WORDY,
	INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,cec65b0a3ccd802d
X-Google-Attributes: gid103376,public
From: "Nick Roberts" <Nick.Roberts@dial.pipex.com>
Subject: Re: Big-endian vs little-endian
Date: 1999/02/02
Message-ID: <7982p9$nll$3@plug.news.pipex.net>#1/1
X-Deja-AN: 439963712
References: <36B155D2.2E8573BB@wvu.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Organization: UUNET WorldCom server (post doesn't reflect views of UUNET
 WorldCom)
Newsgroups: comp.lang.ada
Date: 1999-02-02T00:00:00+00:00
List-Id: <comp.lang.ada>

I can think of two possible solutions:

(a) declare a type derived from Interfaces.Integer_8/16/32 etc. (RM95 B.2),
and then apply a Bit_Order representation clause (RM95 13.5.3) to this type;

(b) use Text_IO instead of Sequential_IO, and input and output the data in
the form of text.

The advantage of (b) is that text is the most universal data format: non-Ada
programs will (almost always) be able to use the data (if that's what you
might ever require). The disadvantage is that the text uses up more storage
than its equivalent binary form. How much data do you have?

The problem with (a) is that it isn't applicable to real types. Nor will it
work if your compiler is an Ada 83 (rather than 95) compiler.

Power to your ulna.

-------------------------------------------
Nick Roberts
-------------------------------------------