the buildbot "AMD64 W2k8 trunk" systematically fails with the messages:

======================================================================
FAIL: test_specialtypes (test.test_sys.SizeofTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 534, in test_specialtypes
    self.check_sizeof({}, h + 3*l + 3*p + 8*(l + 2*p))
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 431, in check_sizeof
    self.assertEqual(result, size, msg + str(size))
AssertionError: wrong size for <type 'dict'>: got 272, expected 224

======================================================================
FAIL: test_standardtypes (test.test_sys.SizeofTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 455, in test_standardtypes
    self.check_sizeof(True, h + l)
  File
"S:\buildbots\python.x64\trunk.nelson-win64\build\lib\test\test_sys.py",
line 431, in check_sizeof
    self.assertEqual(result, size, msg + str(size))
AssertionError: wrong size for <type 'bool'>: got 40, expected 32

It seems that this platform is special: sizeof(long)==4 and
sizeof(size_t)==8

The tests still do not pass on the AMD64 W2k8. Surprisingly,
struct.calcsize behaves as expected, but sizeof() on the C level does
not. The former seems to assumes long to be 4 byte in size, the latter
8!

The tests pass until it comes to a situation where the size of long
affects the alignment of the structure end. In this case long and
function.
long's structure is 'lP PP l H' which gives an expected size of

8+8+16+4+2(+2) = 40

At least this how I think it should be and struct.calcsize does,
too. But what seems to be computed is

8+8+16+8+2(+6) = 48.

It appears as if sizeof(long) = 8. The same explanation holds true for
the failure on the function size which is 'lp PP 9l' and
struct.calcsize : 8+8+16+36(+4) = 72
sizeof          : 8+8+16+72     = 104

Now I don't know how I should address this problem. It seems to be
Windows AMD64 specific, but I found a post [1] which indicates that
it's Windows AMD64 on Windows 2K specific. Tests do also fail on the
Win64 XP buildbot, but it gets killed before the verbose output is
generated. I don't have access to such a platform, so I cannot verify
it.

It may also be a problem with struct.calcsize on Win64.

Any suggestions?

[1]
http://www.velocityreviews.com/forums/t491385-different-behavior-of-amd64-compiler-14004031041-on-windows-xp-and-2k.html

I can't quite follow your layout of a longint; in debug mode, I think it is
- 2P (next/prev)
- ssize_t (refcnt)
- P (type)
- ssize_t (size)
- digits

Notice that a ssize_t is 64 bits on Win64, so there shouldn't be any
longs in the structure on Win64.

> long's structure is 'lP PP l H'
No, it's a VAR-sized object, and ob_size is a Py_ssize_t, which is best
represented as a 'P' as you already did for other types. I suggest 'lP
PP P H'.

> the function size which is 'lp PP 9l'
According to Include/funcobject.h, there are nine PyObject*, the
description should end with "9P".

I think there are some other inconsistencies. For example, the tests for
'list' should be
        self.check_sizeof([], size(h + 'PPP'))
        self.check_sizeof([1, 2, 3], size(h + 'PPP') + 3*self.P)
for the same reasons as for the 'long' type (ob_size is a Py_ssize_t),
even if the total is the same thanks to alignment.

I agree it's very difficult to get it right...

Fixed in r64533.