Author terry.reedy
Recipients brian.curtin, schlamar, terry.reedy, tim.golden
Date 2012-12-22.01:58:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1356141497.0.0.271537080619.issue16743@psf.upfronthosting.co.za>
In-reply-to
Content
The immediate fix is to use a 64 bit build. That aside, what change in behavior are you suggesting? (and for 32 bit builds only?)

Should mmap.mmap warn if the file is longer that would be supported?
This could be added to all current versions.

Should it raise in the same circumstance? What is a person *knows* that the file is 'too big' but only wants to access the first gigabyte? Forcing people to explicitly pass the magic number 1073741824 would, to me, effectively be a 3.4-at-best api change.

Perhaps mmap.mmap should be left alone and only the attempt to access beyond the cutoff should raise or warn. (Is the 32-bit cutoff OS specific?) Given that there are multiple access methods and methods that access, and that all accesses are ultimately delegated to the os mmap functions, this could be major nuisance to get right.

Now that disks have grown to larger than a gigabyte, the doc should explicitly mention the memory space issue.
History
Date User Action Args
2012-12-22 01:58:17terry.reedysetrecipients: + terry.reedy, tim.golden, brian.curtin, schlamar
2012-12-22 01:58:17terry.reedysetmessageid: <1356141497.0.0.271537080619.issue16743@psf.upfronthosting.co.za>
2012-12-22 01:58:16terry.reedylinkissue16743 messages
2012-12-22 01:58:14terry.reedycreate