> So maybe the fix should be to special case zero in PyLong_AsVoidPtr, and
> turn 0L back into NULL there?

Yes, of course. If we have a special case in PyLong_FromVoidPtr(), it is wrong 
that we do not have the special case in PyLong_AsVoidPtr(). But this will 
change the current (potentially buggy) behaviour. ;-)

The patch long_fromvoidptr_2.patch contains such changes (as you want).

But this changes are buggy too, because now PyLong_FromVoidPtr() and 
PyLong_AsVoidPtr() are multivalued. PyLong_FromVoidPtr() maps to 0 NULL and 
may be yet another pointer, PyLong_AsVoidPtr() maps to NULL 0 and may be yet 
another integer.

The patch long_fromvoidptr_3.patch is more consistent in this sense. Now both 
functions are univalued, 

> I think it's just too risky to change the current behaviour in 3.2 and 3.3,
> given the number of places that PyLong_FromVoidPtr is used.  

Buggy behaviour changed if we fix the bug.

> Unlike you, I
> don't have confidence that there are no current or future platforms that
> don't map NULL to 0.

I just want to say that I'm not sure whether to fix this bug. But if we fix it 
for purity, it should be fixed right.