Re: CRC in Ada?

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Tom Moran said

<<  Yes, you did misunderstand.  The original post implied that the
comparison had taken place several years ago, which implies it was done
in Ada 83, which did not implement Stream_IO.  The only "strictly in
Ada" way to read a file then was via Text, Sequential, or Direct_IO.
Both Sequential and Direct_IO require fixed size records. (Not strictly
true, but essentially true in practice.  E.g., ActivAda, GNAT, and Janus
will all accept a "(string)" as the parameter to Sequential_IO, but all
three die on trying to actually read a text file in chunks that way.) So
the fixed buffer size, if one did *not* use Text_IO, would have to be a
divisor of the total file size.  If the file size is a prime number,>>

Actually this is wrong, you cannot even assume that Direct_IO will work
even if the file size is comfortably divisible by a convenient record
size. There is nothing to suggest that the mapping of Direct_IO files
is direct at the byte level, and for example, it would be perfectly
reasonable to have a control byte that showed whether a record was
present, or even a tag to verify the type of the data from run to run.

But in any case, from a language design point of view, this is of
archeological interest only, since one would not consider using 
Direct_IO for this purpose in Ada 95 anyway. If you are trying to
solve this problem with an old Ada 83 compiler, certainly the best
thing is to interface to C.

Unlike Tom (and some others), it never worries me to interface to C where
that is appropriate (or to interface to any other language). The idea that
everything must be done in Ada, and it is a terrible thing to use any
other language seems peculiar to me, and is something that is better left
on the dust heap of Ada relics. I realize that there are Ada fanatics who
feel very differently (though from his posts I would not have thought of
Tom as one), but to me Ada is a tool to be used in the most effective
way possible, and if the most effective way in some particular instance
is to interface to C, that's no problem -- why else have we put such
effort into designing this interface to C portably and effectively (it
certainly *is* more of a problem if you are in C or C++ and have to
interface portably to, e.g. COBOL or Fortran, since it cannot be done
in a portable manner).