[Python-Dev] A Subtle Bug in Class Initializations

[Eddie Elizondo]

Hi everyone, 

Sorry for the delay - I finally sent out a patch: https://bugs.python.org/issue34522.

Also, I'm +1 for modifying all extension modules to use PyType_FromSpec! I might lend a hand to start moving them :)

- Eddie

On 8/13/18, 6:02 AM, "Erik Bray" <erik.m.bray at gmail.com> wrote:

    On Fri, Aug 10, 2018 at 6:49 PM Steve Dower <steve.dower at python.org> wrote:
    >
    > 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.
    
    Ah, that's not exactly what *I* meant, but you are also right: In
    principle it shouldn't have anything to do with the binary formation.
    You could stuff a more sophisticated dynamic relocation section into a
    PE/COFF binary too but Windows wouldn't know what to do with it.
    
    So you're right that this kind of problem could affect other OSes, I
    just have no idea if it does.
    
    > >>> 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?
    
    Both! I think we should fix the built-in types, but it would be nice
    if more extension modules used PyType_FromSpec, if nothing else
    because I find it much more readable, and (I'm guessing) it's better
    from the perspective of Victor's C-API work.  But I admit I'm not
    fully versed in the downsides (if there are any).