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.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,919012a7fc17ce29
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-09-08 12:33:07 PST
Path: 
 nntp.gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!swiss.ans.net!newsgate.watson.ibm.com!watnews.watson.ibm.com!ncohen
From: ncohen@watson.ibm.com (Norman H. Cohen)
Newsgroups: comp.lang.ada
Subject: Re: reading a file containing both text and binary data
Date: 8 Sep 1994 18:07:26 GMT
Organization: IBM T.J. Watson Research Center
Distribution: world
Message-ID: <34njsu$17fu@watnews1.watson.ibm.com>
References: <9409022042.aa16676@paris.ics.uci.edu>
Reply-To: ncohen@watson.ibm.com
NNTP-Posting-Host: rios8.watson.ibm.com
Date: 1994-09-08T18:07:26+00:00
List-Id: <comp.lang.ada>

In article <9409022042.aa16676@paris.ics.uci.edu>,
self@bordeaux.ICS.UCI.EDU (John Self) writes: 

|> At any point I can tell what the format of the next data item should
|> be, but I can't think of an Ada-like way to read different data types
|> (including text) from the same file.  I can use rep specs to read any
|> single data type by using Sequential_IO, but is there any Ada-like way
|> to read a file containing multiple types?  The only ideas I've had so
|> far involve instantiating Sequential_IO to read 8 bits at a time and
|> pack things into the appropriate data types manually with
|> UNCHECKED_CONVERSION.  In some sense I really am doing an "unchecked
|> conversion" since the files really are just sequences of bytes that
|> were generated by a piece of hardware, but I'd like to have take
|> advantage of any nice structuring ideas Ada can give me.

Unchecked_Conversion is a feature of Ada.  Features of Ada are Ada-like.
Therefore Unchecked_Conversion is Ada-like.

When you say "Ada-like," I suspect you really mean "strongly typed."  The
problem is that your file is inherently weakly typed.  You need an
interface between the weakly typed file and the strongly typed program,
with operations like Read_16_Bit_LE_Integer and Read_32_Bit_BE_Integer.
It is reasonable to use Unchecked_Conversion, together with an
instantiation of Sequential_IO that reads a byte at a time, to IMPLEMENT
this low-level interface.  (On the other hand, to convert, say, a 16-bit
little-endian representation in the file to a value of type Integer in a
way that does not depend on whether Integer itself is represented
big-endian or little-endian, it would make sense to use a computation
like

   256*Second_Byte + First_Byte

instead of Unchecked_Conversion.  But the issue here is making your
program endian-independent rather than avoiding a feature because it is
not "Ada-like.")

--
Norman H. Cohen    ncohen@watson.ibm.com