2.3 -> 2.4: long int too large to convert to int

[Grant Edwards]

On 2005-09-16, Raymond L. Buvel <levub137 at wi.rr.com> 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