> >> In obmalloc.c there is some code that does not strictly conform to > >> ANSI C. > > > > True. If we wanted to strictly conform to ANSI C, we couldn't do many > > things we do. > > Sure, but this one is a little bit more eccentric than the others... Hm... Do you have a suggestion for making the code more ANSI conformant? Surely checking whether an address is within a certain range shouldn't require accessing any out-of-bounds memory? Or am I mistaken about how the offending piece of code works? > > I haven't heard of platforms where turning off pymalloc is required -- > > unless we hear about those, I expect that for 2.4, pymalloc may no > > longer be optional. (The reason: maintaining two versions of the same > > code is a pain, and usually the version that's not selected by default > > is severely broken after a few releases.) > > Is this a real problem with pymalloc? > > #ifndef PYMALLOC > #define PyObject_Alloc malloc > #else > ... > #endif > > isn't likely to bitrot that fast. But, whatever, it's no big deal to > me. If that's all, it probably isn't a big deal. :-) [Doing anything to avoid having to look at the actual code...] --Guido van Rossum (home page: http://www.python.org/~guido/)
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