saa added the comment:
Ok, put a fork in me, 'cuz I'm done with this. The latest is that
mmap.size() is defined to return the size of the file and not the size
of the data. It tries to return it as a ssize_t, which of course, on
systems where off_t is 64-bits and ssize_t is 32-b
saa added the comment:
Notes on the problem.
The Python mmap documentation says: If length is 0, the maximum length
of the map will be the current size of the file when mmap is called.
Currently, on a system where off_t is 64-bit and size_t is 32-bit, if
the size of the file (st_size) is
saa added the comment:
There are bigger problems here. When the code calculates the size to map
if size is passed as zero, it simply assigns the 64-bit st_size to the
size to mmap. On a 32-bit system, it is obvious that the amount to map
must be less than a 32-bit value. The calculation
saa added the comment:
Thanks again, revised patch attached.
Added file: http://bugs.python.org/file12376/mmap_off_t_2.patch
___
Python tracker
<http://bugs.python.org/issue4
saa added the comment:
Ah, I think I'm beginning to understand. Thanks for the explanation. So,
if I understand correctly, I should refactor the patch and just remove all
of the Py_off_t and just use off_t because the standard says that *is* the
type. Co
saa added the comment:
Sorry, I should have explained that the bulk of my patch was derived from
existing code. The code that references fpos_t is basically a cut and
paste of code from Modules/bz2module.c. I don't know if this is a valid
usage of fpos_t, but if it isn't,
New submission from saa :
In trying to use the mmap offset to allow me to work with a 12GB file, I
encountered the fact that the new offset parameter was a ssize_t, which
is only 32 bits on my platform (OS X). The mmap offset in C is defined
to be an off_t
(http://opengroup.org/onlinepubs
