PyMem_MALLOC (was [Python-Dev] Snake farm) (original) (raw)
Guido van Rossum guido@python.org
Fri, 22 Nov 2002 13:26:16 -0500
- Previous message: PyMem_MALLOC (was [Python-Dev] Snake farm)
- Next message: PyMem_MALLOC (was [Python-Dev] Snake farm)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 MALLOCZERORETURNSALWAYSTHESAMETHING, which would cover this and similar implementations (i.e. you test malloc(0) == malloc(0)). Another test would be MALLOCZERORETURNSNOMEMORY: 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/)
- Previous message: PyMem_MALLOC (was [Python-Dev] Snake farm)
- Next message: PyMem_MALLOC (was [Python-Dev] Snake farm)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]