on both Unix (SVR4 and BSD) and Windows. Restores behaviour of passing -1
for anonymous memory on Unix. Use MAP_ANONYMOUS instead of _ANON since
the latter is deprecated according to Linux (gentoo) man pages.
Should we continue to allow mmap.mmap(0, length) to work on Windows?
0 is a valid fd.
Will backport bugfix portions.
In C++, it's an error to pass a string literal to a char* function
without a const_cast(). Rather than require every C++ extension
module to put a cast around string literals, fix the API to state the
const-ness.
I focused on parts of the API where people usually pass literals:
PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type
slots, etc. Predictably, there were a large set of functions that
needed to be fixed as a result of these changes. The most pervasive
change was to make the keyword args list passed to
PyArg_ParseTupleAndKewords() to be a const char *kwlist[].
One cast was required as a result of the changes: A type object
mallocs the memory for its tp_doc slot and later frees it.
PyTypeObject says that tp_doc is const char *; but if the type was
created by type_new(), we know it is safe to cast to char *.
mmap_find_method(): this obtained the string to find via s#, but it
ignored its length, acting as if it were \0-terminated instead.
Someone please run on Linux too (the extended test_mmap works on Windows).
Bugfix candidate.
type.__module__ behavior.
This adds the module name and a dot in front of the type name in every
type object initializer, except for built-in types (and those that
already had this). Note that it touches lots of Mac modules -- I have
no way to test these but the changes look right. Apologies if they're
not. This also touches the weakref docs, which contains a sample type
object initializer. It also touches the mmap test output, because the
mmap type's repr is included in that output. It touches object.h to
put the correct description in a comment.
This gives mmap() on Windows the ability to create read-only, write-
through and copy-on-write mmaps. A new keyword argument is introduced
because the mmap() signatures diverged between Windows and Unix, so
while they (now) both support this functionality, there wasn't a way to
spell it in a common way without introducing a new spelling gimmick.
The old spellings are still accepted, so there isn't a backward-
compatibility issue here.
Check for slice/item deletion, which calls slice/item assignment with a NULL
value, and raise a TypeError instead of coredumping. Bugreport and suggested
fix by Alex Martelli.
return a (C) long: PyArg_ParseTuple and Py_BuildValue may not let us get
at the size_t we really want, but C int is clearly too small for a 64-bit
box, and both the start parameter and the return value should work for
large mapped files even on 32-bit boxes. The code really needs to be
rethought from scratch (not by me, though ...).
1) it didn't obey the "start" parameter (and when it does, we must validate
the value)
2) the return value needs to be an absolute index, rather than relative to
some arbitrary point in the file
(checking CVS, it appears this method never worked; these changes bring it
into line with typical .find() behavior)
Versions are defined for Windows and Unix; the Unix
flavor uses sysconf() to get the page size; this avoids
the use of getpagesize(), which is deprecated and
requires an additional library on some platforms
(specifically, Reliant UNIX).
This partially closes SourceForge bug #113797.
undefined. ccording to MvL, this is safe: the MS_SYNC flag means that
msync() returns when all I/O operations are scheduled; without it, it
waits until they are complete, which is acceptable behavior.
* After discussion with Trent, all INT_PTR references have been removed in favour of the HANDLE it should always have been. Trent can see no 64bit issues here.
* In this process, I noticed that the close operation was dangerous, in that we could end up passing bogus results to the Win32 API. These result of the API functions passed the bogus values were never (and still are not) checked, but this is closer to "the right thing" (tm) than before.
Tested on Windows and Linux.
Checkin that replaces the INT_PTR types with HANDLEs still TBD (but as that is a "spelling" patch, rather than a functional one, I will commit it seperately.
comments, docstrings or error messages. I fixed two minor things in
test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").
There is a minor style issue involved: Guido seems to have preferred English
grammar (behaviour, honour) in a couple places. This patch changes that to
American, which is the more prominent style in the source. I prefer English
myself, so if English is preferred, I'd be happy to supply a patch myself ;)
just for the sake of it.
note that this only covers the unlikely case that size_t
is smaller than a long; it's probably more likely that
there are platforms out there where size_t is *larger*
than a long, and mmapmodule cannot really deal with that
today.
I discovered the [MREMAP_MAYMOVE] symbol is only defined when _GNU_SOURCE is
defined; therefore, here is the change: if we are compiling for linux,
define _GNU_SOURCE before including mman.h, and all is done.
The seek() method is broken for any 'whence' value (seek from
start, current, orend) other than the default. I have a patch
that fixes that as well as gets mmap'd files working on
Linux64 and Win64.
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
The bug is in mmap_read_line_method(), and its loop that searches for
newlines. After the loop reaches EOF, eol is incremented and points
after the end of the memory. This results in readline() method
sometimes picking up and returning a byte after the end of the string.
This is usually a bogus \0, but it could cause SIGSEGV if it's after
the end of the page).
The patch fixes the problem. Also, it uses memchr() for finding a
character, which is in fact the "strnchr" the comment is asking for.
memchr() is already used in Python sources, so there should be no
portability problems.
Reformatted for 8-space tabs and fitted into 80-char lines by GvR.
Mark writes:
* the Win32 version now accepts the same args as the Unix version.
The win32 specific "tag" param is now optional. The end result is
that the exact same test suite runs on Windows (definately a worthy
goal!).
* I changed the error object. All occurences of the error, except
for 1, corresponds to an underlying OS error. This one was changed
to a ValueError (a better error for that condition), and the module
error object is now simply EnvironmentError. All win32 error
routines now call the new Windows specific error handler.
Thomas Wouters
Martin v. Löwis
Neal Norwitz
Jeremy Hylton
Armin Rigo
Georg Brandl
Andrew M. Kuchling
Skip Montanaro
Guido van Rossum
Mark Hammond
Tim Peters
Greg Stein
Fred Drake
Fredrik Lundh