PyMem_MALLOC (was [Python-Dev] Snake farm)

[Guido van Rossum]

> 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/)