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 meador.inge
Recipients Suman.Saha, amaury.forgeotdarc, belopolsky, meador.inge
Date 2011-09-22.02:30:45
SpamBayes Score 8.029131e-09
Marked as misclassified No
Message-id <1316658646.76.0.373991259566.issue13013@psf.upfronthosting.co.za>
In-reply-to
Content
This patch seems reasonable.  Upon looking at the code in more
detail, however, I can't see how the error condition that leaks the
reference can ever by triggered.  In particular, the following code
from the 'PyCArrayType_from_ctype' function:

    if (!PyType_Check(itemtype)) {
        PyErr_SetString(PyExc_TypeError,
                        "Expected a type object");
        return NULL;
    }

'PyCArrayType_from_ctype' is only called from 'CDataType_repeat'.  The
'CDataType_repeat' function is only used to implement the 'sq_repeat' 
slot in 'CDataType_as_sequence'.  'CDataType_as_sequence' is used in all 
of the implemented ctypes (struct, array, union, simple, ...).

Unless 'PyCArrayType_from_ctype' is called through some other means
(it is public), then 'itemtype' should *always* be a type.  Or am 
I missing something obvious?  So, we could add the decref or just remove 
the type check code all together (and make 'PyCArrayType_from_ctype'
private).
History
Date User Action Args
2011-09-22 02:30:46meador.ingesetrecipients: + meador.inge, amaury.forgeotdarc, belopolsky, Suman.Saha
2011-09-22 02:30:46meador.ingesetmessageid: <1316658646.76.0.373991259566.issue13013@psf.upfronthosting.co.za>
2011-09-22 02:30:46meador.ingelinkissue13013 messages
2011-09-22 02:30:45meador.ingecreate