Re: Advice on low level file handling.

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

"Peter C. Chapin" <pchapin@sover.net> wrote in message
news:Xns9798DDB851DB4pchapinsovernet@198.186.192.137...
>
> I'm working on a program that needs to read an input file on a byte by
byte
> basis and examine bit fields and do bitwise shifting in some of these
> bytes. Other parts of the file are to be treated as uninterpreted data
> (this is an OpenPGP message file). Right now I'm using
Interfaces.Unsigned_
> 8 as the type to hold a single byte from the file and I'm instantiating
> Ada.Sequential_IO with this type to get the necessary file reading
> subprograms. So far this seems okay, but I'm wondering if this is the most
> appropriate way to do this.

Why aren't you using Stream_IO for this? You don't need to declare your own
types for this sort of I/O. Perhaps you thought that you could only use
Stream_IO with the stream attributes? Actually, I think it is more useful to
use by itself, especially in the sort of case you have here. Byte at a time
I/O can be painfully slow; Stream_IO lets you input a batch of stuff and
then process it.

>...Is that portable? I'm not extremely worried about
> portability, but I'd rather not sacrifice it for no reason.

A machine might not have Unsigned_8 (like the U2200, it has Unsigned_9
instead); but there is going to be a definition of Stream_Element. On the
vast majority of machines, that will be an 8-bit entity.

OTOH, if you *must* have an 8-bit byte, then I'd suggest declaring it
yourself and using Sequential_IO as you did.

> I can define a 64 bit modular type and that seems to work
> fine on gnat. Is that portable?

Not really, but an Ada compiler will reject the program if it doesn't work.
(As someone else pointed out, many Ada compilers don't support 64-bit
numbers.) But it's probably portable enough for your purposes; there isn't
much point in working around the lack of 64-bit math until you actually have
to work on a compiler that doesn't support it.

                                     Randy.