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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4