The final read is not guaranteed to be 32 bits, you should check $n to see how many bytes were read from the stream. I'm not sure of the behavior of unpack if you don't feed it enough data. Since you're using Big-Endian, it may see your final read as much larger than expected.
Your final line $checksum %= 2^32, is going to constrain your checksum to be mod 2^32. If that's what you want, then, yes, it should work.
You're doing your bit match in Big-Endian. Is there any chance that the code you're trying to match does it little-endian? Your B in unpack and N in pack match endianness, so that's good.
Suggestion: make a 4 byte test file and run the other checksum program on it. Use this as the basis for your first test of your checksum program. Then progress to a 5 yte test file, to test the question about the truncated final read.
perldoc read:
Note the characters: depending on the status of the filehandle, either (8-bit) bytes or characters are read. By default all filehandles operate on bytes, but for example if the filehandle has been opened with the :utf8 I/O layer (see "open", and the open pragma, open), the I/O will operate on UTF-8 encoded Unicode characters, not bytes.
In reply to Re: Difficulty producing correct checksum
by spazm
in thread Difficulty producing correct checksum
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |