Juha Manninen wrote:
Wow, with long input data strings it is 10 * faster!
But, bummer, it returns a different value. :(
Our CRCs are stored around in DBs and we need the same value.
I thought CRC algorith is a standard but apparently not.
<GUFFAW> Sorry, that was uncalled for.
I can't speak for highly-optimised algorithms or for SIMD stuff, and
would also suggest that the appropriate implementation depends on
whether you're checksumming an entire buffer or are doing it byte-by-byte.
There's lots of different algorithms, which may be defined by starting
value, polynomial, and whether the value is negated at various points.
Even assuming the same length, the CRC varies depending on the
application: CRCs were originally designed to detect the type of
impulsive errors you'd get on a comms line so to some extent depended on
the bit rate relative to the predominant electrical noise which was
typically non-random. For applications other than that, e.g. to verify a
block of text which might be corrupted randomly, a cryptographic hash is
better.
I've used them quite a lot over the years. A couple of years ago I was
interfacing to a piece of test equipment and used the CRC units from
http://www.wolfgang-ehrhardt.de/crchash_en.html to explore arbitrary
message blocks and identify which CRC each appeared to use and (hence)
where each one ended. I believe they can be classes as freeware, and I
think they could usefully be added to FPC.
Another useful resource for those with plenty of time on their hands is
http://www.quadibloc.com
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
