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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,305f22b27bd2e6cb
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-11-05 02:15:03 PST
Path: 
 archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.vmunix.org!newsfeed.stueberl.de!teaser.fr!oleane.net!oleane!nnrp.oleane.net!not-for-mail
From: Thierry Lelegard <thierry.lelegard.NOSPAM@cptechno.NOSPAM.com>
Newsgroups: comp.lang.ada
Subject: Re: Read Binary File
Date: Wed, 05 Nov 2003 11:11:32 +0100
Organization: CANAL+ TECHNOLOGIES
Message-ID: <3FA8CCD4.DEA23A81@cptechno.NOSPAM.com>
References: <6449213e.0311030756.64346802@posting.google.com>
NNTP-Posting-Host: host227.canal-plus.fr
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: s1.read.news.oleane.net 1068027094 17020 194.2.208.227 (5 Nov 2003
 10:11:34 GMT)
X-Complaints-To: abuse@oleane.net
NNTP-Posting-Date: Wed, 5 Nov 2003 10:11:34 +0000 (UTC)
X-Mailer: Mozilla 4.78 [fr]C-C+  (Windows NT 5.0; U)
X-Accept-Language: fr,en,zh-CN,zh-TW
Xref: archiver1.google.com comp.lang.ada:2071
Date: 2003-11-05T11:11:32+01:00
List-Id: <comp.lang.ada>

> Situation: OpenVMS, Alpha, Ada '83.  Binary file created by C++ program.
>            Use_Error raised on first byte.  We regularly read Ada-generated
>            binary files, but the C++ source in new.

Classical problem of logical file contents vs. physical file contents.
This is the kind of problem that primitive operating systems (*) with
flat files do not have...

On VMS, the physical content is managed by the file system (XQP) while
the logical content is managed by the Recode Management System (RMS).

Have a look (dir/full) at the binary files which were created by Ada
Sequential_IO (Byte) and by C++. Their attributes are quite different,
this is why they are not interpreted the same way.

I would guess that the Ada-created files have attribute
"fixed record size, 2 bytes". Dump them in this case, I guess
that the content is 1st data byte, zero, 2nd data byte, zero, etc.

The reason is:
- Sequential_IO creates "fixed record size" files.
- RMS always starts a new record on even bytes, using one zero
  byte padding if the record size is odd.

Note that this zero padding is just a "hidden implementation detail"
of the physical content. Reading the file using RMS (which is used
by Sequential_IO) only returns the logical content, that is to say
one byte for each record in your case, since a "record" (logical
unit of the logical content) is one byte.

Note that DEC C and DEC C++ do not use RMS since those "primitive" 
languages were based on the "primitive" operating system they come
from (UNIX). So, unless you use special file creation options, the
C/C++ runtime does not use RMS, it directly use XQP (actually RMS
Block-IO, but this is the same level of content as XQP). C-created
files do not have any "logical" content, they just have a "physical"
content on a VMS standpoint.

To raad them from another language, you have two options (assuming
that you cannot modify the C++ program to generate the files in a
different format):

- Modify the file attributes so that the (numodified) physical content
  matches the implementation of some logical content. Then, read the
  file according to the new logical content. This is a hack but it
  works if carefully understood.

- Do it the simple way and directly read the physical contents.

To implement this in Ada:

First option:
- Force a different logical view of the file using the DCL command:
       set file /attribute=(rfm=fix,mrs=2,lrl=2) filename
  Your file keeps its physical content but the logical interpretation
  of this  physical content has changed to: fixed record size, 2 bytes.
- Instanciate Sequential_IO on a type "array (1..2) of Byte"
  (instead of "Byte").
- Read the content of the file 2 bytes per 2 bytes.
- Warning: If the file size is odd, you will most certainly get
  a Use_Error on the last byte.

Second option (I personally would use this one):
- Give up high-level Ada I/O packages and directly read the physical
  content of the file using RMS Block-IO. This, however, needs some
  familiarity with RMS.

-Thierry
(*) Don't flame, just joking...