Re: Encapsulating Ada.Direct_IO

["Randy Brukardt" <randy@rrsoftware.com>]

"Peter C. Chapin" <pcc482719@gmail.com> wrote in message 
news:w6udneqaMqdi83jRRVn_vwA@giganews.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?

Adam is right. What we did is the same thing as the C compiler.

When you imported files from the "real world" into that system, it added a 
zero bit to every byte. So there normally would not be any such thing as a 
file with 8-bit characters.The same thing happened to sockets.

The real trouble came when you did the reverse, as it then *dropped* the 
high bit if it thought that the files were text files. That would be bad 
news for truly binary files.

Ada can only define things portably that it has control over. If you read 
and write files on the same machine, then the results should be portable. 
Once you start communicating to other machines, there can be translation 
layers that mess things up.

The good new is that it is pretty rare that you will have to deal with any 
machines that have other than 8-bit bytes these days. So I wouldn't worry 
about those issues unless you happen to be working with Unisys. ;-)

                                             Randy.