Calculating a 32 bit CRC

[bmanske]

I started working with PPL and the first thing I noticed was the abseence of bit manipulation operators.* I explained to Kornalius what was needed, he made it a reality and I set out to test it using this program.</p>

*In case you are not familiar with a CRC, it is a Cyclic Redundancy Check.* This CRC generator creates a number that is 32 bits (4 bytes) in length.* It is implemented in hardware in almost every network card in the world and in software in programs like WinZip to verify that the data in the file is valid.</p>

Just download the attached file and unzip it.* I included the test file (a wav) that I have been using, but it can work with any file, just change the filename in the define at the top of the program.* It demonstrates the use of the console, using sprintf to format output strings, how to read from a file and of course bit manipulation.</p>

There is just one problem, it doesn't work.* Yep.* Last night I sat for about 2 hours looking at this code wondering why it didn't work.* I hadn't compiled or run it in a long time.* Some bug that was allowing it to work before, was fixed in the compiler and now it fails to generate a good CRC.* I figured, &quot;Why should I alone have all of the fun?&quot;</p>

Here is the challenge, fix the CRC bug.* All of the CRC values that get printed by each of the 4 methods*are all different now.* After the fix they will all be the same.* Here is the hint: all you have to do is open the file add only ONE character then save and run the file.</p>

Understanding why this is happening requires some pretty good understanding of bit-manipulation.* Who will be the first to post the solution?* If this isn't answered in a week, I will post the solution with an explanation.* Anybody want to play?</p>[br]1159653991_5_FT0_crc32.zip [/html]

[kornalius]

I would give another hint if I were you Brad. ;)

[bmanske]

The character that needs to be added is a &quot;u&quot;. So ask yourself, where can I add a &quot;u&quot; that would effect all 4 methods at once and how could this &quot;u&quot; effect bit operations?

I'm going out of town for the weekend, so I'll have to write up the solution/explanation when I get back on Monday.

Brad

[bmanske]

There are very few places in the code that effect all 4 methods of calculating a CRC at the same time. The line that needs changed is 193
type(CRC32_1$, CRC32_2$, CRC32_3$, CRC32_4$, tint);

While PPL takes great pride in being typeless as possible, sometimes you just can't escape it. In this case these vars all needed to be &quot;tuint&quot; or unsigned integers.

Why unsigned? Because of the right shift operation. PPL correctly performs an arithmetic shift right on signed variables. So if you are implementing a divide using a shift operation, the sign of the variable will be maintained (whatever valuse the Most Significant Bit has, it stays that value). In this case, unsigned variables are required so that when doing the shift, the most significant bit always receives a '0'.

This little nugget of knowledge probably isn't in the manual, I'll see that it gets in there. Have I explained this well enough?

I was hoping that this would generate some interesting discussion, but I must have made it too difcult or nobody was interested. Please let me know what you think.

Brad

[kornalius]

Brad, is it tuint or tint? You mentionned both. In the first line of code you put tint and then further down in your explanation you say &quot;tuint&quot;.

[PointOfLight]

I can't believe I'm even admitting this, but I feel like a real idiot. I thought you meant something needed to be changed in the data file. Changing something in the code file makes a lot more sense, but I must have been having one of those &quot;brain lapse&quot; moments.