CRC32

[Scott Wolfington]

Hi!

I've been playing around with the CRC32 code in the source code
library. Most of the time the value that gets returned from
the code is an 8 digit hex number. Once in a while it comes
back with a 7 digit hex number. Now, this doesn't happen with
the same file of course, but I ran it against approximately 150
different files and 5 of them came back with a 7 digit CRC. I
was hoping that it would always come back with a fixed length
CRC. Is there any way to acheive this? Could this source code
ever have a return value that is less than 7 digits long or
more than 8 digits long? Thanks in advance!

Scott

[Greg Turgeon]

Scott--
   
If you want to know more about CRCs, try the following link:
   
 [url="http://www.repairfaq.org/filipg/LINK/F_crc_v3.html"]http://www.repairfaq.org/filipg/LINK/F_crc_v3.html[/url] 
   
It might tell you more than you want to know, but it certainly offers 
enough to help make CRCs more understandable. 
   
As for their length, they're 16-bit or 32-bit (with odd, 
special-purpose mutations also existing here and there).  Their 
length is in fact fixed.  If you see seven digits displayed on 
screen, then the zero on the left is just not being shown.  Revise 
the code so that it displays HEX$(CRC???, 8), and you'll see the 
entire value.

[This message has been edited by Greg Turgeon (edited July 25, 2000).]

[Mark Newman]

A side note: If you're using CRC-32 to interface with "external" sources,
such as a comm port, ftp, etc., be aware that there are different "CRC-32"
implementations out there that return different checksum values on the
same data stream.


------------------
Mark Newman

[Scott Wolfington]

Thank you gentleman!

Greg, the HEX$(CRC???, 8) worked perfectly.

I've got another question. I turned that CRC32 code into
a .dll. It should be thread safe, right? A dll will be
thread safe if it's not using any globals, right? What else
is necessary for a .dll to be thread safe? Thanks
in advance!

Scott

[Tom Hanlin]

Make sure all variables are local to a SUB or FUNCTION. If another SUB or FUNCTION needs access to a value, pass it as a parameter. Don't use STATIC variables.

Computational programming is generally thread-friendly by nature. Programming that involves input or output is generally not thread-friendly by nature, as the results may get thrown off if some other thread is also doing I/O. Consider the FREEFILE and DIR$ functions, for example.

A detailed discussion of threads is way beyond the scope of one message. Check the FAQ and/or your friendly neighborhood bookstore for more detailed information.

------------------
Tom Hanlin
PowerBASIC Staff