[EMAIL PROTECTED] schrieb: >> Subject: Python CTypes translation of (pv != NULL)
I've started a wiki page where I already added an entry about the above question. Do you think the entry would have answered your question? http://starship.python.net/crew/theller/moin.cgi/CodeSnippets (My wiki should really be upgraded to a newer moinmoin version, however it might be better to use another wiki for ctypes, maybe the python.org one, for this stuff.) > And so then the next related Faq is: > > Q: How should I test for ((void *) -1)? > > A: > > (pv == 0xffffFFFF) works often. > > (ctypes.cast(pv, ctypes.c_void_p).value == 0xffffFFFF) works better. > > ((void *) -1) appears often in 32-bit Windows, behind the name > INVALID_HANDLE_VALUE of the type HANDLE that is def'ed as the type > PVOID that is def'ed as (void *). -1 is xffffFFFF in 32-bit two's > complement. > > The more complex comparison works more often because specifying a > restype doesn't decide the __class__ of the result. True, in principle. For me, on Windows, c_void_p(-1).value is the same as c_void_p(0xFFFFFFFF).value, but it is -1 not 0xFFFFFFFF. Worse, on 64-bit systems c_void_p(-1).value is 184467440737009661615, which is the same as 0xFFFFFFFFFFFFFFFF. So, to be portable, INVALID_HANDLE_VALUE should be defined like this: INVALID_HANDLE_VALUE = c_void_p(-1).value and your test would become (ctypes.cast(pv, ctypes.c_void_p).value == INVALID_HANDLE_VALUE Thomas PS: It is inconsistent that the .value of a c_void_p instance is signed on 32-bit systems, and unsigned on 64-bit systems, but it seems we have to live with that. Fortunately, the c_void_p constructor accepts both signed and unsigned Python ints and longs, so it should be possible to work around that fact. -- http://mail.python.org/mailman/listinfo/python-list
