[PyKDE] sipTypeDef structure layout and invalid casts

[Dave Cuthbert]

[Apologies if this appears twice -- I didn't realize that posting via 
gmane wasn't the right way of sending to this list...]


I'm currently debugging some custom QCanvasItem subclasses wrapped by
PyQt -- this is a bit of an unfriendly case, since QCanvasItem doesn't
use the standard MOC metaobjects, but has its own rtti() method <sigh>...

Anyway.  We're on commercial versions of SIP 4.0rc3 + latest patches,
PyQt 3.11 + some patches to allow us to subclass from QCanvasItems.  Our
module is named "tokyo", which I'll use in my code excerpts below.


The issue I'm running into is the casting of sipTypeDef structures into
sipWrapperTypes.  siptokyocmodule.cpp contains an area like:

====
static sipWrapperType *typesTable[] = {
	(sipWrapperType *)&sipType_TextUI,
	(sipWrapperType *)&sipType_EditBuffer,
	(sipWrapperType *)&sipType_GSelectionTableItem,
	/* ... */
	0
};
====

Each sipType_XXXX structure is a sipTypeDef defined something like (for
TextUI):

====
/* The main type data structure. */
sipTypeDef sipType_TextUI = {
	0,
	"tokyo.TextUI",
	-1,
	supers_TextUI,
	0,
	5, methods_TextUI,
	0, 0,
	0,
	init_TextUI,
	dealloc_TextUI,
	cast_TextUI,
	forceConvertTo_TextUI,
	0,
	sipNewProxy_tokyo,
	signals_TextUI,
	{0, 0, 0, 0, 0, 0}
};
====

The problem is that this layout doesn't match sipWrapperType, which is
defined in sip.h as:

====
typedef struct _sipWrapperType {
	PyHeapTypeObject super;		/* The super-metatype. */
	struct _sipTypeDef *type;	/* The additional type information. */
} sipWrapperType;
====

I'm not sure how this is supposed to work.  A sipWrapperType "inherits"
from PyHeapTypeObject, which inherits from PyTypeObject; sipTypeDef
looks nothing like this, so I think the casts are invalid.

My crash is happening when we try to downcast and end up sending these
structures into Python as a PyTypeObject (we either see serious stack
corruption or coredumps deep in Python itself).

Any insight?  I think this is a SIP bug, but I could just be
misunderstanding something.

Thanks.
Dave Cuthbert
dacut at neolinear.com