ctypes.c_void_p(-1) might not be C return (void *) -1

[p.lavarre]

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 == 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. 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 == 0xffffFFFF,
print pv == 0xffffFFFF,
print pv, pv.__class__
test(c_void_p(-1))
test(passlib.passback(-1))
$

All true? All bogus? Partly bogus? Curiously yours, Pat LaVarre

 

[Thomas Heller]

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.

 

[p.lavarre]

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.

...

For me, on Windows, c_void_p(-1).value is the same
as c_void_p(0xFFFFFFFF).value, but it is -1 not 0xFFFFFFFF.

Different results at my desk. Specifically, I see:

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 0xFFFFFFFFFFFFFFFF.
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...">

 

[Thomas Heller]

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.


Different results at my desk. Specifically, I see:


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.

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?


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(0xFFFFF...) 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.

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)