 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Cyclic Redundancy Checking |
|
 |
Anonymous Poster |
|||
 Posted - 5/17/2003 1:38:00 AM |
||||
| just wondering why you store your functions/data in a class with since they are all static... it would make more sense to use a namespace. |
||||
|
||||
|
MattB Member since: 8/5/2001 From: British Columbia, Canada |
|||
|
Posted - 5/18/2003 12:48:23 AM |
||||
| CRC, MD5, SHA, etc. are all hashing algorithms, whether you use them for security purposes or not. I think MD5 is probably a better solution for maintaining file integrity. A lot of sites offer MD5 hashes to compare against downloaded files. |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 5/18/2003 7:32:24 AM |
||||
| Hi, I think there is a little mistake by "Calculating for a file". for( dwLoop = 0; dwLoop < dwBytesInOut; dwLoop++ ); GetCRC32( cBuffer[ dwLoop ], dwCRC32 ); The ";" after the for-Loop is wrong or ? MfG Unwissender |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 11/7/2003 9:32:09 PM |
||||
| I was just wondering: Say you've got a large block of contiguous data. You already know the CRC32 values for several small sections of that data (of unequal size, but you know the size covered by each). Together, the CRC32 values you have covers the entire block of data with no overlaps, and you know what order they appear in. Can you derive a valid CRC32 value for the entire block of data using only the precalculated CRCs? (possibly also referring to the order and size of each) -- *without* using the raw data itself? |
||||
|
||||
|
KernelJ Member since: 11/17/2007 From: Carlisle, United Kingdom |
|||
|
Posted - 11/17/2007 11:34:05 AM |
||||
| There is a subtle problem in the code, which could cause it to give completely wrong CRCs in situations where BYTE has to be used as a signed datatype (and therefore the processor movsx instruction would be used instead of movzx). This would cause negative indexed elements of CRC32Table (because of the extension 0xFFFFFFXX), and obviously that won't work (it didn't crash for me it just gave the wrong value). The fix is simple... inline void ECRC32::GetCRC32(const BYTE byte, DWORD &dwCRC32){ dwCRC32 = (( dwCRC32 ) >> 8 )^ CRC32Table[( byte )^(( dwCrc32 ) & 0x000000FF )]; } to... inline void ECRC32::GetCRC32(const BYTE byte, DWORD &dwCRC32){ dwCRC32 = (( dwCRC32 ) >> 8 )^ CRC32Table[(( byte )^( dwCrc32 )) & 0x000000FF ]; } By doing the operations in this order the bitmask will be applied to the whole expression and negative indices would be impossible. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
