No announcement yet.


  • Filter
  • Time
  • Show
Clear All
new posts



    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 Wolfington

    If you want to know more about CRCs, try the following link:
    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).]


      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
      Mark Newman


        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 Wolfington


          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