[Python-Dev] initializing ob_type

Greg Stein gstein@lyra.org
Fri, 19 Jan 2001 17:21:56 -0800


On Fri, Jan 19, 2001 at 12:11:02PM -0800, Mark Hammond wrote:
> > you can compile the module as C++, but that's also a bit painful...
> 
> My understanding is that the C std doesn't guarantee the order of static
> object initialization, whereas C++ does provide these semantics.  At least
> that is the excuse I found when digging into this some years ago.

True, but when PyWhatever_Type is initialized, &PyType_Type ought to be
ready (even if it isn't initialized). Heck, &PyType_Type points into the
Python core which is *definitely* loaded by that point.

Now, if "initialization" also means "relocation to a specific address" then
I can understand.

Hrm... I've just spent some time with the Windows SDK docs, and I can't find
anything that really discusses the problem and resolution. There certainly
isn't any warning about "don't do this." It all talks about how fixups are
stored with the DLL, how you can optionally use BIND to pre-bind the values,
blah blah blah. But nothing saying "it doesn't work."

It would be interesting to know more about the actual symptoms that appears
when the ob_type init is performed by the structure (rather than at
runtime). What happens? Bad address? NULL value? Failure to resolve and
load? Is PyType_Type not exported correctly or something?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/