mmap on large files on 64 bit platforms in python >=2.5 returns some
sort of garbage.  In 2.4 it would just throw an exception.  Now I get
something like this (script runs md5.md5 on mmap object, and then runs
os.system md5sum for comparison):

This is python2.5 from Ubuntu 8.04 AMD64
/tmp$ python2.5 testbigfile.py 
python mmap md5: 1230552d39b7c1751f86bae5205ec0c8
abe59e28c9a3f11b883f62c80a3833a5 *bigfile


This is python svn as of 20080601, compiled the on same system.
/tmp$ python2.6 testbigfile.py
testbigfile.py:5: DeprecationWarning: the md5 module is deprecated; use
hashlib instead
  import md5
python mmap md5: 1230552d39b7c1751f86bae5205ec0c8
abe59e28c9a3f11b883f62c80a3833a5 *bigfile


Also note how the python md5 call returns immediately, not something you
would expect when md5ing 4GB of data.

Actually, I just realized that this might be a problem with md5 module
instead.  Either way, something is busted.

I tested this with python 2.6 and can confirm the issue.
The problem is that unsigned int isn't big enough to hold the size of
the objects, but the size is downcasted to an unsigned int at several
places in _hashopenssl.c. All of these occurences of Py_SAFE_DOWNCAST
seem problematic to me (Py_SAFE_DOWNCAST(len, Py_ssize_t, unsigned int))

the same bug also occurs when computing the md5 of a string larger than
2**32

So would anybody like to contribute a patch?

this patch adds a digest_update function.
digest_update calls EVP_DigestUpdate(..) with chunks of 16 MB size and
also checks for signals.
I didn't write any tests (as they will most probably annoy many people
cause they would need much memory).

testbigfile.py however now works.

same issue in http://bugs.python.org/issue3886.
it's sad that no one took a look at the patch...
now, it should probably be closed...

Ok, closing. Thanks for the patch, anyway.