Re: ctypes.c_void_p(-1) might not be C return (void *) -1
[EMAIL PROTECTED] schrieb: 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 As concise as I now can imagine, yes thank you. I see the main point leads: The truth value of any NULL ctypes pointer instance is False. That angle neatly ducks my ongoing newbie confusion over a null constructed in Python via c_void_p(0) being different from a null constructed in C via return (void *) 0. ... And so then the next related Faq is: Q: How should I test for ((void *) -1)? For me, on Windows, c_void_p(-1).value is the same as c_void_p(0x).value, but it is -1 not 0x. Different results at my desk. Specifically, I see: from ctypes import * ; c_void_p(-1).value 4294967295L in Mac OS X 10.4.7 Python 2.5 r25:51918 and Win XpSp2 Python 2.5 r25:51908. You are right, I was using my own private build of ctypes which behaves differently. With Python 2.5 on Windows, I get the same as you. Worse, on 64-bit systems c_void_p(-1).value is 184467440737009661615, which is the same as 0x. So, to be portable, INVALID_HANDLE_VALUE should be defined like this: INVALID_HANDLE_VALUE = c_void_p(-1).value Exactly what I should have written, yes, thank you. And somewhat generalisable: c_void_p(0).value is None. Maybe this is the thing that's been astonishing me: maybe C often does return the .value of the pointer, rather than a new instance of the POINTER class? and your test would become (ctypes.cast(pv, ctypes.c_void_p).value == INVALID_HANDLE_VALUE Yes. Mind you, typing out all that noise inspires me to ask, does (pv == INVALID_HANDLE_VALUE) give the wrong answer for any pv other than c_void_p(-1)? In other words, if by convention I get all my pointers from C and never construct a pointer in Python except to take its value, then can I safely write the more obvious translation of (pv == INVALID_HANDLE_VALUE)? Well, c_void_p(-1).value is the same as c_void_p(0xF...) for a sufficient number of F's, so to speak. The integer or long value you pass to c_void_p is masked with a bitmask haing all bits set to '1' as the platform's (void *) type has. 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. Obviously, as you discovered, and I confirmed, this is no longer true. In the Python2.5 ctypes, the value of c_void_p is always unsigned. I just meant that we have to live for quite some time with the behaviour of ctypes as implemented, because only bug fixes can be made to Python 2.5. Thomas (I'll probably leave for a few days now) -- http://mail.python.org/mailman/listinfo/python-list
ctypes.c_void_p(-1) might not be C return (void *) -1
Subject: Python CTypes translation of (pv != NULL)
And so then the next related Faq is:
Q: How should I test for ((void *) -1)?
A:
(pv == 0x) works often.
(ctypes.cast(pv, ctypes.c_void_p).value == 0x) 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 x 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. For example, the
run below shows a type 'long' result value passed back from a C
routine that has a c_void_p restype:
$ gcc -o passlib.so -dynamiclib -Wall passlib.c
$ python results.py
True False c_void_p(4294967295L) class 'ctypes.c_void_p'
True True 4294967295 type 'long'
$
$ cat passlib.c
void * passback(int ii)
{
return (void *) ii;
}
$
$ cat results.py
from ctypes import *
passlib = cdll.LoadLibrary('./passlib.so')
passback = _fx = passlib.passback
_fx.restype = c_void_p
_fx.argtypes = [c_int]
def test(pv):
print cast(pv, c_void_p).value == 0x,
print pv == 0x,
print pv, pv.__class__
test(c_void_p(-1))
test(passlib.passback(-1))
$
All true? All bogus? Partly bogus? Curiously yours, Pat LaVarre
--
http://mail.python.org/mailman/listinfo/python-list
Re: ctypes.c_void_p(-1) might not be C return (void *) -1
[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 == 0x) works often. (ctypes.cast(pv, ctypes.c_void_p).value == 0x) 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 x 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(0x).value, but it is -1 not 0x. Worse, on 64-bit systems c_void_p(-1).value is 184467440737009661615, which is the same as 0x. 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
Re: ctypes.c_void_p(-1) might not be C return (void *) -1
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 As concise as I now can imagine, yes thank you. I see the main point leads: The truth value of any NULL ctypes pointer instance is False. That angle neatly ducks my ongoing newbie confusion over a null constructed in Python via c_void_p(0) being different from a null constructed in C via return (void *) 0. ... And so then the next related Faq is: Q: How should I test for ((void *) -1)? For me, on Windows, c_void_p(-1).value is the same as c_void_p(0x).value, but it is -1 not 0x. Different results at my desk. Specifically, I see: from ctypes import * ; c_void_p(-1).value 4294967295L in Mac OS X 10.4.7 Python 2.5 r25:51918 and Win XpSp2 Python 2.5 r25:51908. Worse, on 64-bit systems c_void_p(-1).value is 184467440737009661615, which is the same as 0x. So, to be portable, INVALID_HANDLE_VALUE should be defined like this: INVALID_HANDLE_VALUE = c_void_p(-1).value Exactly what I should have written, yes, thank you. And somewhat generalisable: c_void_p(0).value is None. Maybe this is the thing that's been astonishing me: maybe C often does return the .value of the pointer, rather than a new instance of the POINTER class? and your test would become (ctypes.cast(pv, ctypes.c_void_p).value == INVALID_HANDLE_VALUE Yes. Mind you, typing out all that noise inspires me to ask, does (pv == INVALID_HANDLE_VALUE) give the wrong answer for any pv other than c_void_p(-1)? In other words, if by convention I get all my pointers from C and never construct a pointer in Python except to take its value, then can I safely write the more obvious translation of (pv == INVALID_HANDLE_VALUE)? 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. I'm interested, if you can make the time to say more ... 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. Good. ... might be better to use another wiki for ctypes, maybe the python.org one, for this stuff.) ... Could be. Offline I heard we might have more pages coming soon. Checking at random just now, I see http://wiki.python.org/moin/ is immutable, so I guess I can't add A Wiki page to collect the Faq's highlit by Clp to the Starting points Asking for Help Wanted... -- http://mail.python.org/mailman/listinfo/python-list
