By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,987 Members | 967 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,987 IT Pros & Developers. It's quick & easy.

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

P: n/a
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

Sep 28 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
p.*******@ieee.org 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/thel...i/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.

Sep 28 '06 #2

P: n/a
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/thel...i/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(0xFFFFFFFF).value, but it is -1 not 0xFFFFFFFF.
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 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...">

Sep 28 '06 #3

P: n/a
p.*******@ieee.org 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/thel...i/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(0xFFFFFFFF).value, but it is -1 not 0xFFFFFFFF.

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 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)?
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.
>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)

Sep 29 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.