Tests fails on Windows, Python3, 64bit machine, likely due to float == double on windows about persistent HOT 6 CLOSED

Although, skipping may not be that great an option. It's not just the test that's failing, apparently. The first test failure is actually showing a bug, the C and Python versions are different:

   self.assertEqual(hash(c), hash(py))
AssertionError: 2875592705 != -1419374591

from persistent.

#39 does it. All builds green.

from persistent.

@jamadden I'm befuzzled: do you have a clue how to deal with tine Windows ABI-compatible-with-Win95 insanity here?

from persistent.

@tseaver Sorry, I know I wrote this test initially. I don't know what the right fix is, though. And my Windows VM bit the dust, so I don't currently have access to experiment/test there. My only suggestion would be to skip this one on 64-bit Win?

from persistent.

ctypes.sizeof(c_long()) == 4 may be a better way to spell is_32_bit.

Except, it looks like is the problem that ctypes.c_long doesn't match what the actual extension module thinks of as long. (Because if it did match, I don't understand why hash( c) != hash(py))

from persistent.

I think I may have found it, and it's a bug in the C code. The C hash function is defined as static long TimeStamp_hash(self). But the hashfunc slot is defined to return a Py_ssize_t.

On 64-bit windows, Py_ssize_t is 8 bytes long, where long is 4 bytes.

I instrumented both the Python and C implementations, and verified that they both return the same on 64-bit windows; but by the time the internal magic of C and/or the interpreter have their way with the return type, -1419374591 becomes 2875592705.

If I fix the return type, all the tests pass on Windows.

I have to verify the signature of hashfunc on 2.7 (been testing on 3.5) and check a sane platform, but if that holds up, PR coming.

from persistent.