[PATCH 4 of 5] mpatch: remove dependency on Python.h in mpatch.c

Yuya Nishihara yuya at tcha.org
Thu Aug 11 04:27:20 EDT 2016


On Wed, 10 Aug 2016 16:43:46 +0200, Maciej Fijalkowski wrote:
> On Fri, Aug 5, 2016 at 3:54 PM, Yuya Nishihara <yuya at tcha.org> wrote:
> > On Mon, 25 Jul 2016 15:10:58 +0200, Maciej Fijalkowski wrote:
> >> # HG changeset patch
> >> # User Maciej Fijalkowski <fijall at gmail.com>
> >> # Date 1469201285 -7200
> >> #      Fri Jul 22 17:28:05 2016 +0200
> >> # Node ID 8e2d1b2d5248620ff4ccfcb61e1b383cf0e4e204
> >> # Parent  e7436cb7226d5216b18d25560a14331871b804c0
> >> mpatch: remove dependency on Python.h in mpatch.c
> >
> >> diff --git a/mercurial/mpatch_module.c b/mercurial/mpatch_module.c
> >> --- a/mercurial/mpatch_module.c
> >> +++ b/mercurial/mpatch_module.c
> >> @@ -33,12 +33,33 @@
> >>  static char mpatch_doc[] = "Efficient binary patching.";
> >>  static PyObject *mpatch_Error;
> >>
> >> +struct mpatch_flist *cpygetitem(void *bins, ssize_t pos)
> >> +{
> >> +     const char *buffer;
> >> +     struct mpatch_flist *res;
> >> +     ssize_t blen;
> >> +     int r;
> >> +
> >> +     PyObject *tmp = PyList_GetItem((PyObject*)bins, pos);
> >> +     if (!tmp)
> >> +             return NULL;
> >> +     if (PyObject_AsCharBuffer(tmp, &buffer, (Py_ssize_t*)&blen))
> >> +             return NULL;
> >> +     if ((r = mpatch_decode(buffer, blen, &res)) < 0) {
> >> +             if (!PyErr_Occurred())
> >> +                     PyErr_SetString(mpatch_Error, mpatch_errors[-r]);
> >
> > Maybe it should raise MemoryError if r == MPATCH_ERR_NO_MEM.
> >
> > Other than that, this patch looks good to me.
> 
> Maybe it should, but this is replicating the way the C version works I
> think (?). My theory is that the versions should not differ much in
> terms of behavior, even though guaranteeing sane behavior when you're
> out of memory is plain impossible in python

The original implementation would raise MemoryError. I've fixed it in that
way. Also, I think it's generally possible to handle out of memory caused
by one big malloc(), not by a lot of malloc()s of small objects.


More information about the Mercurial-devel mailing list