Re: Binary files vs Portablity vs Ada

[Ted Dennison <dennison@telepath.com>]

In article <7vurt3$ojd$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <7vt67r$qv0$1@coward.ks.cc.utah.edu>,
>   nahaj@u.cc.utah.edu (John Halleck) wrote:
> >   Is there even a portable way to get the "raw" bits for a
> >   file that works on all machines supporting Ada?  (So that it
> >   can be handed to a bit oriented version of SHA.)
>
> Sure, have a look at Ada.Streams.Stream_IO


You do have to be somewhat careful there. There's a whole lot about
streams that is implmentation dependent. For one thing, there's no
guarantee that you are really reading the "raw" (whatever that means)
bits from the file when you do a stream IO operation, unless you wrote
the stream's Read and Write routines yourself. There's no reason to
expect that your vendor would do something goofy with the data (like
compress it or something), but there's nothing stopping them either.

There may be portability issues with the IO attributes as well. For
instance, what exactly does Integer'Write send to the stream's Write
procedure? The language doesn't specify it. In one instance here we were
trying to 'Read data on one machine that was 'Written on another using
the same code compiled with a different vendor's compiler (big
mistake!). Among other portability problems, one vendor had implemented
'Write on arrays to send the elements in the array to the stream in
*reverse* order. I believe that's probably against the LRM (It says
elements are written in "cannonical" order), but the point is that
unless you write everything yourself, the only thing you can really
count on when you are using default stream implementations is that 'Read
will be able to retrieve what 'Write wrote, if both were compiled with
the same compiler on the same platform.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Before you buy.