Added a test to test_bitfields.py:
    def test_uint32(self):
        class X(Structure):
            _fields_ = [("a", c_uint32, 32)]

        x = X()
        x.a = 10
        self.failUnlessEqual(x.a, 10)

Run in Python 2.5.2 and 2.6.2:
======================================================================
FAIL: test_uint32 (__main__.BitFieldTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_bitfields.py", line 73, in test_uint32
    self.failUnlessEqual(x.a, 10)
AssertionError: 0L != 10

Also run in 3.0

What's your platform? I could reproduce this on windows. And I found 
attached patch can workaround this.

One of the new tests in r74134 is failing on my box (Gentoo x86), and on
a number of the buildbots:

test test_ctypes failed -- Traceback (most recent call last):
  File "/home/rdmurray/python/trunk/Lib/ctypes/test/test_bitfields.py",
line 255, in test_uint64
    self.failUnlessEqual(x.a, 10)
AssertionError: 0L != 10

> One of the new tests in r74134 is failing on my box (Gentoo x86), and on
> a number of the buildbots:

I've seen that, but do not yet have a patch.

ctypes_workaround_2.patch from ocean-city seems to fix it so I'll apply
that.

I glanced at my patch again, and I noticed it has a problem.
SET() cannot handle type larger than unsigned int on windows.
I'll recreate the patch...

Here is at least better, simple patch. But ideally,
mask should be created from variable type. "short" mask
should be created for "short" variable, "long long" mask
for "long long" variable, vise verse.

I'll create such patch next. I hope it's final solution.

////////////////////////////////////////
// This works on attached patch.

from __future__ import print_function
import ctypes
class Blah(ctypes.Structure):
    _fields_ = [("a", ctypes.c_uint64, 64),
                ("b", ctypes.c_uint16, 16),
                ("c", ctypes.c_uint8, 8),
                ("d", ctypes.c_uint8, 8)]

x = Blah(0xFEDCBA9876543210,0xBEEF,0x44,0x12)
print(Blah.a, hex(x.a))
print(Blah.b, hex(x.b))
print(Blah.c, hex(x.c))
print(Blah.d, hex(x.d))

Sorry，my patch didn't work again... Because of this
compiler behavior. Is this ANSI standard?

#include <stdio.h>

typedef unsigned __int32 uint32;

static void
print_bits(uint32 n)
{
    int i;

    for (i = 31; i >= 0; --i)
    {
        printf("%c", (n & (1 << i)) ? '1' : '0');
    }
    printf(" : %X\n", n);
}

int main()
{
    uint32 n;

    n = 1;
    print_bits(n << 30);
    print_bits(n << 31);
    print_bits(n << 32);
    print_bits((n << 31) << 1);
}

R:\test\bitshift>a
01000000000000000000000000000000 : 40000000
10000000000000000000000000000000 : 80000000
00000000000000000000000000000001 : 1
00000000000000000000000000000000 : 0

I thought n << 32 should be 0. I hope new patch
is somehow better.

This patch removes MAX_SIZE_INT limitation. I hope this
is final patch. I confirmed all ctypes test passed on
my environment. (Windows, VS8.0)

I have a similar patch for issue 6068. I wasn't aware of this issue when I looked into it.

I believe both patches fix the same thing (please take a look and correct me if I'm wrong). My fix: we don't need to treat Windows differently, just remove #ifdef and 

#define BIT_MASK(size) ((1LL << NUM_BITS(size))-1)

regardless of platform. Unittests for this patch pass for my patch too. I believe this is some old #ifdef that was put in place due to a compiler bug which got fixed since then.

Hirokazu's v3 patch is a clean solution for the issue and works on 3.2 

any update on when it will go into 3.2/3.3? I can help if needed

The problem is with the 'BIT_MASK' macro, which is currently defined as the following for Windows:

   #define BIT_MASK(size) ((1 << NUM_BITS(size))-1)

The C standard says that any attempt to shift left by exactly the bit width is undefined behavior.  For the given test case 'NUM_BITS(size) == 32' and the '1' constant is of type 'int'.  Thus the behavior is undefined.

For x86 Windows with the MSVC++ compiler this ends up as 'SAL edx, CL' and the Intel manuals say that the shift count is masked by 0x1F.  Thus the bit mask ends up as '(1 << 0) - 1 == 0'.  Plug the zero mask into the 'SET' macro and you will see why the reported behavior is being observed.

I tested Hirokazu's last patch on Windows 7 64-bit and OS X 10.7;  I saw no regression.  I will apply the patch shortly.

New changeset 77401bd4f567 by Meador Inge in branch '2.7':
Issue #6493: Fix handling of c_uint32 bitfields with width of 32 on Windows.
http://hg.python.org/cpython/rev/77401bd4f567

New changeset 153ae76b963e by Meador Inge in branch '3.2':
Issue #6493: Fix handling of c_uint32 bitfields with width of 32 on Windows.
http://hg.python.org/cpython/rev/153ae76b963e

New changeset 3fbfa61634de by Meador Inge in branch 'default':
Issue #6493: Fix handling of c_uint32 bitfields with width of 32 on Windows.
http://hg.python.org/cpython/rev/3fbfa61634de