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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!uunet!inmet!stt
From: stt@inmet.inmet.com
Newsgroups: comp.lang.ada
Subject: Re: File I/O Question
Message-ID: <20600039@inmet>
Date: 12 Apr 90 14:10:00 GMT
References: <54727@bbn.COM>
Nf-ID: #R:bbn.COM:54727:inmet:20600039:000:1329
Nf-From: inmet.inmet.com!stt    Apr 12 10:10:00 1990
List-Id: <comp.lang.ada>


Regarding reading files with multiple record types:

The language-defined I/O packages don't handle this
kind of file, at least not without standing on your head.
However, it seems to be a little known fact that it is
permissible to write your *own* I/O packages!  

I am only being a little facetious here.  It is important to realize
that the Ada Reference Manual provides only a starting point for I/O services.
It does not define any standard interface to the underlying
O/S I/O services, though most Ada vendors provide such packages.
Even if your vendor doesn't provide such an I/O package, it
is almost always possible to use pragma Interface to Assembler
or C to accomplish the job.  By the way, the Posix/Ada folks are making good
progress on standardizing an Ada interface to Posix (Unix) I/O services.

Perhaps Ada9X will try to directly address some of these very real problems,
but alternatively, it may instead focus on providing the primitives
(refinements to 'ADDRESS, 'SIZE, and unchecked-conversion) so that
application-specific I/O packages will be easier to write in a portable,
compiler-independent way.  In any case, judicious use of 'ADDRESS, 'SIZE,
and Unchecked_Conversion can go a long way already toward easing
the solution to your I/O problems.

S. Tucker Taft
Intermetrics, Inc.
Cambridge, MA  02138