[Python-Dev] A Subtle Bug in Class Initializations

[Steve Dower]

On 10Aug2018 0354, Erik Bray wrote:
> Thanks!  I'm not sure what you mean by "on other OS's" though.  Do you
> mean other OS's that happen to use Windows-style PE/COFF binaries?
> Because other than Windows I'm not sure what we care about there.
> 
> For ELF binaries, at least on Linux (and probably elsewhere) it the
> runtime loader can perform more sophisticated relocations when loading
> a binary into memory, including relocating pointers in the binary's
> .data section.  This allows it to initialize data in one executable
> "A" with pointers to data in another library "B" *before* "A" is
> considered fully loaded and executable.
> 
> So this problem never arises, at least on Linux.

That's exactly what I meant. I simply didn't know how/whether other 
loaders handled this case :) I recognise it's nothing to do with the 
binary format and everything to do with whether the loader knows what to 
do or not.

>>> So I'm +1 for requiring passing NULL to PyVarObject_HEAD_INIT,
>>> requiring PyType_Ready with an explicit base type argument, and maybe
>>> (eventually) making PyVarObject_HEAD_INIT argumentless.
>>
>> Since PyVarObject_HEAD_INIT currently requires PyType_Ready() in
>> extension modules already, then don't we just need to fix the built-in
>> types?
>>
>> As far as the "eventually" case, I'd hope that eventually extension
>> modules are all using PyType_FromSpec() :)
> 
> +1 :)

Is that just a +1 for PyType_FromSpec(), or are you agreeing that we 
only need to fix the built-in types?

Cheers,
Steve