Guido van Rossum <guido@python.org> writes: >> 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... >> However, I do not believe there have been reports of machines >> in the wild where this is a problem, and on such platforms there is an >> easy solution: turn off pymalloc. > > I think there is talk though to make it impossible to turn off > pymalloc in the future (you can still turn it off in Python 2.3). > > 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. Cheers, M. -- People think I'm a nice guy, and the fact is that I'm a scheming, conniving bastard who doesn't care for any hurt feelings or lost hours of work if it just results in what I consider to be a better system. -- Linus Torvalds
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