>>>From the algorithm it looks as if you could easily end up with a negative result regardless of file size.
>>>I don't know the inner workings of the calculation but, since it is essentially a bitwise operation, why do you thing negative int representations are invalid (you don't show any usage of the nCRC32 return value) ?
>>
>>I saw it like that since the last two years. I always assumed it could be ok to have negative values. But, yesterday, we compared a related class in Visual FoxPro for CRC32 to mine and we did not obtain the same results on big files. We were obtaining the same values for small files but not on big ones. So, I assumed mine was wrong.
>
>Rather then the VFP :-}

I'll chime in.... <g>

I think a negative number is incorrect, but only because logically a CRC should be treated as Unsigned.

It's not actually a number, it's a code.

The unsigned VFP number and the signed VB number are probably the same binary bit pattern. It's just that when you convert it to a string VB sees that it is a signed number and translates it as a two's compliment since the high order bit is set.

The problem with using unsigned int for this arises when you try and store it to a database that doesn't support unsigned integers so even though unsigned may make better logical sense, you may still want to use signed.

I think this should give you the twos compliment in VFP if you need to work with the same "numeric" value in both systems.

? IIF(vfpCRC>=2^31,vfpCRC - (2^32),vfpCRC)

One weird thing... you say you only see negative numbers on large files, I just did a quick list on a single field in a table and about half of them came up negative using the above calculation. (Which is what I would expect)