Re: Encapsulating Ada.Direct_IO

["Peter C. Chapin" <pcc482719@gmail.com>]

On 2010-11-18 11:36, Adam Beneschan wrote:

> I have a longish rant that touches on this, but the short answer is
> that I don't think there's an Ada answer to your question.  If you had
> a file defined as using 8-bit units, and that file got put onto a
> system that uses 36-bit words, you'd need to know just what the OS is
> going to do with it, and how the particular Ada implementation will
> deal with files on that OS.  It may be that the native "read from
> file" service on that OS will put each byte into a 9-bit byte and zero
> the high bit.  I don't see how to avoid implementation-dependent code
> in a case like this.

I understand what you are saying but it is less than satisfying. :)

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."

I want to write an Ada program that can read in a file like this and
process it. Are you saying that it's impossible to write such a program
in a portable manner?

What I've been doing is as I showed earlier... define my own "Byte" type
with Byte'Size set to 8 and the instantiate Sequential_IO. My program
then interprets the individual bytes as necessary. It seems to work with
GNAT.

I suppose that C has the same issue, really. The C standard does not
promise that char is exactly 8 bits. If it isn't I'm not sure what
happens when you do

int Ch;

while ((Ch = fgetc(infile)) != EOF ) { ... }

I guess that's the same point you are making. Maybe the C standard talks
about this issue. Checking...

I just took a quick look at C99's description of fgetc and it says, "the
fgetc function returns the next character from the input stream." That
seems to beg the question, doesn't it?

Peter