>>>>>>>>>>>>(1) The short way is to cast the return result to UInteger, and change the return type of GetCrc32() to UInteger
>>>>>>>>>>>
>>>>>>>>>>>This line cannot be changed to UInteger:
>>>>>>>>>>>
>>>>>>>>>>>

>>>>>>>>>>>        Dim lnCRC32Result As Integer = &HFFFFFFFF
>>>>>>>>>>>

>>>>>>>>>>>
>>>>>>>>>>>It would give an error: "Constant expression not representable in type 'UInteger"
>>>>>>>>>>
>>>>>>>>>>Yes, it seems vb interpretes those as signed
>>>>>>>>>>
>>>>>>>>>>http://msdn.microsoft.com/en-us/library/s9cz43ek.aspx
>>>>>>>>>>
>>>>>>>>>>Append the type to the constant. U and I
>>>>>>>>>>

>>>>>>>>>>    Dim lnCRC32Result As UInteger = &HFFFFFFFFUI
>>>>>>>>>>

>>>>>>>>>
>>>>>>>>>There you go! Thx, didn't know that syntax existed :-{
>>>>>>>>
>>>>>>>>Well, you know more vb than I do -
>>>>>>>I know VB just well enough to work with it where it maps pretty straightforwardly to C# and that's about it.
>>>>>>>>I just googled my way through
>>>>>>>And I was too lazy :-}
>>>>>>
>>>>>>
>>>>>>I just had the impression you were not in favour of unsigned types ;)
>>>>>
>>>>>As in my post to Michel this AM - for the case in point I just think Int32 is preferable ....
>>>>
>>>>
>>>>Yeah, I read that post
>>>>
>>>>The data is the same, it's just the way looking at it that differs
>>>>
>>>>Michel did not want negative numbers, hence the suggestion to use unsigned
>>>>
>>>>And thinking about it - there must be a reason why unsigned was invented
>>>
>>>I assume simply so that you can store a larger positive number is a 32 bit structure.
>>>BTW, did you read the link that John referenced earlier....
>>
>>
>>Yes, I did read that link the day it was posted - it's a way of reasoning
>>
>>
>>The reason unsigned was invented - I think - was to provide for situations where negative values did not make sense. I'd say that it does not make sense for a crc - but then, that's my opinion
>
>But, as we've both said, for the crc all that matters is the 32-bit pattern. Whether we choose to use Int32 or UInt32 to hold the bit structure won't affect the validity of the bitwise code - just the representation of the result. Going back to the beginning of this thread I think the only reason Michel didn't want a possible negative intertpretation was that he thought it was wrong - which turns out not to be the case.

I concur