This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients amaury.forgeotdarc, nadeem.vawda, serhiy.storchaka
Date 2012-10-29.12:11:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
From Nadeem Vawda's mail:

> I wasn't suggesting that you try to resize the existing unused_data
> object; I agree that this would be a bad idea. What I was thinking of
> was something like this:
>     size_t old_unused_size = PyBytes_GET_SIZE(self->unused_data);
>     size_t new_unused_size = old_unused_size + self->zst.avail_in;
>     PyObject *new_unused_data = PyBytes_FromStringAndSize(NULL, 0);
>     if (_PyBytes_Resize(&new_unused_data, new_unused_size) < 0) {
>         Py_DECREF(RetVal);
>         goto error;
>     }
>     memcpy(PyBytes_AS_STRING(new_unused_data),
>            PyBytes_AS_STRING(self->unused_data),
>            old_unused_size);
>     memcpy(PyBytes_AS_STRING(new_unused_data) + old_unused_size,
>            self->zst.next_in, self->zst.avail_in);
>     Py_DECREF(self->unused_data);
>     self->unused_data = new_unused_data;
> Basically, hacking around the fact that (AFAICT) there's no direct way to
> allocate an uninitialized bytes object. That way we only do one allocation,
> and only copy the new data once.

This hacking is not needed, if first argument of PyBytes_FromStringAndSize() is NULL, the contents of the bytes object are uninitialized. And more, this hacking is invalid, because empty bytes object shared and can't be resized.

Patch updated. The concatenation optimized as you suggested, one bug fixed.
Date User Action Args
2012-10-29 12:11:33serhiy.storchakasetrecipients: + serhiy.storchaka, amaury.forgeotdarc, nadeem.vawda
2012-10-29 12:11:33serhiy.storchakasetmessageid: <>
2012-10-29 12:11:33serhiy.storchakalinkissue16350 messages
2012-10-29 12:11:33serhiy.storchakacreate