• Advertisement
Sign in to follow this  

CRC

This topic is 3354 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok. This has been bothering me for a while. It is simple enough to take a CRC32 of a byte string. CRC32( 0xFFFFFFFF, "c:\" ); And, due to the way a CRC works you could also concatenate onto it by using the old CRC as the start value for the new CRC CRC32( CRC32(0xFFFFFFFF, "c:\"), "gamedata\") == CRC32("c:\gamedata\"); But my quandry is if there is an operation you can do to yield this function CONCAT_CRC32( CRC32(0xFFFFFFFF, "c:\"), CRC32(0xFFFFFFFF, "gamedata\") ) == CRC32("c:\gamedata\"); And if there isn't, what would be a decent hash that would let you do that? There is some background, and I'm sure the system could be fixed so I don't compute CRC32( knownCrcForMyObject, "/someFileName" ), but it allows for selection of runtime decided files, without needed to compile a list of file CRC's for each object to hold onto beforehand. But for some reason my brain keeps telling me that you should be able to just SOMETHING the two CRC numbers and get the third CRC.

Share this post


Link to post
Share on other sites
Advertisement
Nope, a function such as what you want CONCAT_CRC32 to do with CRCs is not possible. As a minimum it would also need to know the length of the second string, but then that's probably not enough either.
I can't recall ANY decent hashes that would accomodate this.
an 8-bit XOR would obviously work, but is pretty much the opposite of decent.

Share this post


Link to post
Share on other sites
Yeah. that is what i feared. And I too though of a simple x-or hash, which would obviously work, but would cause too many name collisions, especially with filenames.
Oh well.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement