Patch from Hrvoje Niksic <hniksic@iskon.hr>:

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.
This commit is contained in:
Fred Drake 2000-04-04 18:17:35 +00:00
parent 7d68690d8d
commit 56a87a0905
1 changed files with 8 additions and 8 deletions

View File

@ -132,20 +132,20 @@ static PyObject *
mmap_read_line_method (mmap_object * self,
PyObject * args)
{
char * start;
char * start = self->data+self->pos;
char * eof = self->data+self->size;
char * eol;
PyObject * result;
CHECK_VALID(NULL);
start = self->data+self->pos;
/* strchr was a bad idea here - there's no way to range
check it. there is no 'strnchr' */
for (eol = start; (eol < eof) && (*eol != '\n') ; eol++)
{ /* do nothing */ }
result = Py_BuildValue("s#", start, (long) (++eol - start));
eol = memchr(start, '\n', self->size - self->pos);
if (!eol)
eol = eof;
else
++eol; /* we're interested in the position after the
newline. */
result = PyString_FromStringAndSize(start, (long) (eol - start));
self->pos += (eol - start);
return (result);
}