> Guido van Rossum <guido@python.org> writes: > > > This can be solved (as MAL suggested) by fixing configure so that > > malloc(0) returning 0x800 is treated the same as malloc(0) returning > > NULL. That way, pymalloc's free code doesn't have to special-case > > this. [MvL] > This is nearly as bad as hard-coding the system on which it > happens. If system developers come to like this trick, they may decide > to return 0xFFFF0000 for malloc(0) (system developers, when confronted > with a non-conformity in their implementation, always love to find a > conforming but surprising implementation). > > Given that this is quite hard to debug if it happens, I'd rather like > to see a better test. It's not easy to find one, though. > > One would be to do MALLOC_ZERO_RETURNS_ALWAYS_THE_SAME_THING, which > would cover this and similar implementations (i.e. you test malloc(0) > == malloc(0)). > > Another test would be MALLOC_ZERO_RETURNS_NO_MEMORY: malloc(0), round > down to the page beginning, read a word there, expect a crash. This > tests precisely the functionality that pymalloc needs. Yes, the test I proposed was naive. But I'd like to see this fixed in configure, not in pymalloc. (Tim seems to favor always ensuring that we never call malloc(0), but I can't see how that can be done without an extra test+jump. :-( ) --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