Integer precision loss in call to CC_MD5_Update

[boredzo]

dd-parallel/PRHMD5Context.m:32:38: Implicit conversion loses integer precision: 'const NSUInteger' (aka 'const unsigned long') to 'CC_LONG' (aka 'unsigned int')

This warning, which appears on LP64 architectures such as x86_64, is correct, and the code has been flagged with a FIXME comment:

		//FIXME: CC_LONG is technically not equivalent to NSUInteger. This should update in chunks until numBytes is exhausted.
		CC_MD5_Update(&_context, bytesPtr, numBytes);

numBytes is typed as NSUInteger (unsigned long), but CC_MD5_Update expects a CC_LONG, which (as the warning says) is defined as unsigned int.

Questionable type definition choices in CommonCrypto notwithstanding, the comment above describes the correct resolution to the warning. CC_MD5_Update should be called in a loop as long as numBytes is greater than UINT_MAX, shaving off UINT_MAX bytes at a time, and then one more time for whatever's left. (When numBytes is less than UINT_MAX to start with, which is 100% of the time, the loop will run zero times.)

This isn't urgent; since the chunk size used in main is 1 MiB, numBytes should generally be no more than that, nowhere near the limit of an unsigned int. Even so, it's good to fix things the right way.

Just changing the type of numBytes won't work; that just moves the problem to main, which passes the ssize_t (signed long) returned by write. The code in main is convoluted enough without introducing this loop there.