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.3 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	INVALID_MSGID,XPRIO autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,11acceb38e90ed0a,start
X-Google-Attributes: gid103376,public
From: "Nick Roberts" <nickroberts@callnetuk.com>
Subject: Sequential_IO Data Portability
Date: 2000/01/25
Message-ID: <38903e96@eeyore.callnetuk.com>#1/1
X-Deja-AN: 578286296
X-Original-NNTP-Posting-Host: da132d212.dialup.callnetuk.com
X-Trace: 27 Jan 2000 12:48:22 GMT, da132d212.dialup.callnetuk.com
X-MSMail-Priority: Normal
X-Priority: 3
Newsgroups: comp.lang.ada
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Date: 2000-01-25T00:00:00+00:00
List-Id: <comp.lang.ada>

A question was asked in GNAT chat recently as to (I hope I paraphrase
closely enough) whether, in general, the data written, via Sequential_IO, by
a brand of Ada compiler for one machine/OS target can be expected to be read
by a program, using the same type and Sequential_IO, compiled by the same
brand of compiler, but for a different target.

I would suggest that the general answer to the question must be 'no', but
that it will be 'yes' in most practical cases. In particular, I would expect
most sensible (professional?) compilers to include no 'dope' in a file
written by Sequential_IO for a type that is definite.

I would suggest that all compilers should include in their documentation the
exact format and meaning of all 'dope' (hidden) data in all I/O facilities
it comes with (I think RM95 M(69) implies this, but only very vaguely, and
Annex M is not normative). Some effort to standardise on this dope data
might also be worthwhile, perhaps?

I think the next Ada revision should make an effort to enforce a level of
documentation. Of course no automated tests could be used to verify this,
but human-level verification is perfectly practical. I'm not advocating a
densely beaurocratic approach.

--
Nick Roberts
http://www.adapower.com/lab/adaos