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 loewis
Recipients asvetlov, gregory.p.smith, jcea, loewis, mark.dickinson, meador.inge, serhiy.storchaka
Date 2012-07-25.09:06:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <500FB710.6090205@v.loewis.de>
In-reply-to <1343203910.38.0.537487048787.issue15402@psf.upfronthosting.co.za>
Content
> Hmm.  I see this usage in a lot of places---e.g. see
> unicode_capitalize, unicode_casefold, unicode_title etc. in
> Objects/unicodeobject.c.  So it looks like we're relying on the
> (PyCFunction) cast to convert from a one-argument function pointer to
> a two-argument function pointer, which sounds a bit worrisome---I
> guess it just happens to work with common ABI calling conventions.
> I'm a bit surprised that we're not seeing compiler warnings about
> this sort of thing.

The compiler has no chance to find out. You cast the pointer to
PyCFunction, telling the compiler that it really is a PyCFunction.

I really wish we could put a ban on function pointer casts, and try
to make this all statically type-correct. This, of course, would
require the sizeof function to take PyObject*, and cast it to
PyStructObject * locally. My idiom for that is

static PyObject *
s_sizeof(PyStructObject *_self, PyObject *unused)
{
  PyStructObject *self = (PyStructObject *)_self;

> It sounds like 'wrong everywhere' is accurate, unfortunately.

"Everywhere" is nowhere close to the truth. There are tons of
NOARGS functions which have the correct signature.
History
Date User Action Args
2012-07-25 09:06:26loewissetrecipients: + loewis, gregory.p.smith, jcea, mark.dickinson, asvetlov, meador.inge, serhiy.storchaka
2012-07-25 09:06:26loewislinkissue15402 messages
2012-07-25 09:06:25loewiscreate