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.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,6353697ffeb79d16
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!news3.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!195.71.90.67.MISMATCH!news.unit0.net!news.mixmin.net!news2.arglkargh.de!news.karotte.org!uucp.gnuu.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Encapsulating Ada.Direct_IO
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: 
 <5ba4147a-6099-4a05-b548-09544f58247a@j18g2000yqd.googlegroups.com>
 <tM6dnaTzn6shVH7RRVn_vwA@giganews.com> <ic1uop$nhs$1@munin.nbi.dk>
 <162dnSHurcNcEHnRRVn_vwA@giganews.com>
 <2edbda42-28e8-462c-9005-eda66538274b@p11g2000vbn.googlegroups.com>
 <w6udneqaMqdi83jRRVn_vwA@giganews.com>
 <0ce12623-198f-42e6-a30a-8e2cb77947be@q18g2000vbm.googlegroups.com>
Date: Thu, 18 Nov 2010 21:15:35 +0100
Message-ID: <r7v04g2g2uci$.l3n3krrc2wt0$.dlg@40tude.net>
NNTP-Posting-Date: 18 Nov 2010 21:15:33 CET
NNTP-Posting-Host: b89b6fa3.newsspool3.arcor-online.net
X-Trace: 
 DXC=Cd8Vl4S_1<D78PK[oJ2ng@McF=Q^Z^V3H4Fo<]lROoRA8kF<OcfhCOK9miZagT93AO[6LHn;2LCVN[<mhadbfdUKP]O?0D27>FNkP2gLYIeMeE
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:16570
Date: 2010-11-18T21:15:33+01:00
List-Id: <comp.lang.ada>

On Thu, 18 Nov 2010 11:48:49 -0800 (PST), Adam Beneschan wrote:

> On Nov 18, 10:21�am, "Peter C. Chapin" <pcc482...@gmail.com> wrote:
> 
>> I'm thinking about the very common case when one is trying to read a
>> file that has a format defined by some third party. For example the
>> specification of the format might say, "The first octet of the header
>> defines the message type and can be one of the following values... The
>> type field is followed by a 24 bit length field in big endian form. The
>> body of the message follows the length field, and finally a 32 bit CRC
>> follows the message body."
> 
> The problem is that this *definition* is not sufficient to tell you
> what an OS will stick in your memory buffer if you ask to read from
> such a file.

I don't think so. I presume that the context of the definition above is the
OS. It is a reasonable presumption because files from another OS (file
system) cannot be read at all unless they are converted into the format
supported by the OS's file system. Another presumption is that the
definition describes memory layout, rather than the media layout. The
latter is inaccessible anyway. So a stream of octets is what a file reading
OS service delivers, when Ada would call it. There of course is no guaranty
that Direct_IO would use this service and not some other service.

> You need additional OS-dependent information.

The Ada compiler vendor will likely document the services used for
Direct_IO, but there is no way to verify that using the representation
clauses and/or assertions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de