As a heads up, Fletcher class of checksum algorithms are reasonably strong because they are specified to perform 1's complement sums (i.e. end around carries [(a + b) mod (2^n -1)]) such that sums don't overflow into oblivion and thereby loose critical information.
Unsigned additions in "C" are not 1's complement additions. As presently implemented (and arguably not even Fletcher checksums), they are incredibly weak, and not even capable of generating unique checksums across large blocks of zero valued data for example, containing single bit errors which are arguably not uncommon. If one reviews carefully correct Fletcher checksum implementations, it will become apparent that either adds with carry are utilized if implemented in assembly language, or larger accumulators are used to compute the sum (such that upper carries are not lost), and then the upper portion of the accumulator are iteratively then added to the lower portion of the sum until no further carries are generated, and thereby effectively performing a 1's complement modular addition. Please consider fixing the implementation, as it's presently deceptively weak, although perceived to be otherwise riding on the coattails of the relative strength of Fletcher checksums, which the implementation is not. [As an aside, as I believe that most otherwise undetected checksum miss matches are most likely caused by the introduction of single bit errors during the transport of data to or from storage or otherwise, having a stronger checksum implementation having a hamming distance of at least 2 although more ideally 3, provides the opportunity to potentially enable the correction of single bit errors with reasonable probability if all else fails in lieu of relying on the data being hopefully archived somewhere else or resulting in catastrophic otherwise.] -- This messages posted from opensolaris.org
