On 2005-09-16, Raymond L. Buvel <[EMAIL PROTECTED]> wrote:
> Grant Edwards wrote:
>> I give up, how do I make this not fail under 2.4?
>>
>> fcntl.ioctl(self.dev.fileno(),0xc0047a80,struct.pack("HBB",0x1c,0x00,0x00))
>>
>> I get an OverflowError: long int too large to convert to int
>>
>> ioctl() is expecting a 32-bit integer value, and 0xc0047a80 has
>> the high-order bit set. I'm assuming Python thinks it's a
>> signed value. How do I tell Python that 0xc0047a80 is an
>> unsigned 32-bit value?
>
> Everyone seems to be suggesting that the fix for the problem
> is to somehow cobble together some way of forcing an unsigned
> integer into a signed integer (what you would do with a cast
> in C). However, if I understand the long<->int consolidation
> this is not consistent with that effort.
>
> As far as I can tell, the underlying problem is that the C
> routine fcntl.ioctl is expecting a signed integer.
Well, that's what the man page says.
In practice it's just expecting an int-sized chunk of bits: it
wants a unique bit pattern to feed to a 'case' statement rather
than an "integer" in the number-line, arithmetic operations
sense of the word. C's implicit coercion rules make it a moot
point, but Python's coercion rules have been changed to be
incompatible with C's. Hilarity ensues. ;)
> These are the kinds of problems that need to be fixed. The
> function should be asking for an unsigned integer. This is
> possible with the C API at least since Python 2.3. Without
> these fixes, the long<->int consolidation is going to continue
> to produce frustration. There are many functions in the
> standard library that you would expect to take unsigned
> integers but actually specify signed integers.
Unfortunately the C API is cast in stone (at least in
comparison to Python standards). I guess somebody could go
through the C-Python code and "lie" to Python about it in order
to fix some of the issues.
What I would really, really like are fixed length integer types
so that I can manipulate 8, 16, 32 and maybe 64 bit, 2's
compliment values. I've seen some pretty good "user-space"
pure-python implimentations, but haven't gotten around to using
them in production yet.
One of the nasty bits in a pure-python approach is that there's
no way to write a literal with a fixed length. For example,
instead of writing 0xf7 to get an 8-bit value and 0x12345789 to
get a 32-bit value, you have to instantiate a class like
Word8(0xf7) and Word32(0x12345678).
That starts to make things pretty hard to read.
--
Grant Edwards grante Yow! Yow! Now we can
at become alcoholics!
visi.com
--
http://mail.python.org/mailman/listinfo/python-list
