Hmmm ...  Assuming  a native VC++ compiler on an x86 machine running Windows, then it doesn't make sense to validate these test cases in such an environment.  All the tests are all big-endian.

'ctypes' can't be expected to behave the same as the native compiler that compiled the Python interpreter for structures of non-native endianities produced by 'ctypes'.  That doesn't make sense.  The best we can do is document how 'ctypes' does handle non-native endianites on various platforms.

FWIW, I did try the first set of tests (http://bugs.python.org/msg88145) with GCC for a 32-bit MIPS ELF target using the following test case:

#include <stdio.h>

struct T {
  unsigned int x : 31;
  unsigned int y : 32;
};

struct S {
  unsigned long long x : 31;
  unsigned long long y : 32;
};

int main (int argc, char **argv)
{
  unsigned char buf[8] = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55};
  struct T *t = (struct T*)&buf;
  struct S *s = (struct S*)&buf;

  printf ("%X, %X\n", t->x, t->y);
  printf ("%X, %X\n", s->x, s->y);
}


The test output:

Data0 is 0x2AAAAAAA, Data1 is 0x55555555 for uint
Data0 is 0x2AAAAAAA, Data1 is 0xAAAAAAAA for ulonglong

is correct with respect to that environment.

The difference in the first case (uint) and the second case (ulonglong) is that the first is placed into two 4-byte unsigned integer units where as the second is placed into one 8-byte unsigned long long unit.

I am slightly confused how issue12528 is going to address this, when there seems to be no bug;  only what seems to be a test case problem.  I think we should close this issue out.

Another issue should be opened to enhance the documentation, though.  We should document exactly how 'ctypes' does the structure layout for different endianities on different platforms.  Something similar to how VC++ documents this ( http://msdn.microsoft.com/en-us/library/ewwyfdbe(v=vs.71).aspx ).