Porting woes

[Jay]

> It checks whether the cls argument to classic_mro really is a classic
> class. It is surprising that it calls into classic_mro. Can you tell
> which line in Py_ReadyTypes comes from? (type, list, string, ...?)

It occurs in the initialization of the type..

> It would be good to study the value of type, and tp_bases, at this
> point. It might be that some initialization of global objects has
> failed to happen, or has happened incorrectly.

Thanks for the suggestion!! It appears as though this particular
problem goes away if I extend the static initialization of the
PyTypeObject PyBaseObject_Type to explicitly set the tp_bases value
(and the other six values that are not explicitly assigned at the end
of the structure to NULL).  If I don't explicitly zero these values,
they pick up whatever happens to be left over in those memory
locations, is it possible that this is a compiler bug?? I assume that
this code compiles correctly on most other compilers, or is zeroing
out memory locations before use an operating system function??

I hope that there aren't other places in Python where structures are
not fully initialized (and I may see a bug of this type again).

Thanks,
Jay

loewis at informatik.hu-berlin.de (Martin v. Löwis wrote in message news:<j4sn041tuz.fsf at informatik.hu-berlin.de>...
> jstavnitzky at atsautomation.com (Jay) writes:
> 
> > This failure is occuring during the function classic_mro().  The
> > stack at that point is
> > classic_mro(),mro_implementation(),mro_internal(),PyType_Ready(),
> > PyTypeReady(),Py_ReadyTypes(),Py_Initialize(),Py_Main().
> > 
> > Help!! What is happening at this point, and what could be causing this
> > assertion to fail?
> 
> It checks whether the cls argument to classic_mro really is a classic
> class. It is surprising that it calls into classic_mro. Can you tell
> which line in Py_ReadyTypes comes from? (type, list, string, ...?)
> 
> None of these are classic classes, so this code should not have been
> executed. It appears that this was executed because of the test in
> 
> 		if (PyType_Check(base))
> 			parentMRO = PySequence_List(
> 				((PyTypeObject*)base)->tp_mro);
> 		else
> 			parentMRO = classic_mro(base);
> 
> i.e. base appears not to be a type. This, again, should not happen:
> base is
> 
> 		PyObject *base = PyTuple_GET_ITEM(bases, i);
> 
> which in turn comes from
> 
> 	bases = type->tp_bases;
> 
> All base types of the types initialized in Py_ReadyTypes have only
> types as bases, so it is surprising that one of them has a base which
> is not a type.
> 
> It would be good to study the value of type, and tp_bases, at this
> point. It might be that some initialization of global objects has
> failed to happen, or has happened incorrectly.
> 
> Regards,
> Martin