Keith Dart firstname.lastname@example.org writes:
I am very concernced about something. The following code breaks with 2.4.1:
fcntl.ioctl(self.rtc_fd, RTC_RD_TIME, ...)
Where RTC_RD_TIME = 2149871625L
In Python 2.3 it is -2145095671.
Well, you could always use "-2145095671"...
Actually, this is supposed to be an unsigned int, and it was construced with hex values and shifts.
But well, quite.
Now, with the integer unification, how is ioctl() supposed to work? I cannot figure out how to make it work in this case.
The shortest way I know of going from 2149871625L to -2145095671 is the still-fairly-gross:
v = 2149871625L ~int(~v&0xFFFFFFFF)
I suppose the best thing is to introduce an "unsignedint" type for this purpose.
Or some kind of bitfield type, maybe.
C uses integers both as bitfields and to count things, and at least in my opinion the default assumption in Python should be that this is what an integer is being used for, but when you need a bitfield it can all get a bit horrible.
That said, I think in this case we can just make fcntl_ioctl use the (new-ish) 'I' format argument to PyArg_ParseTuple and then you'll just be able to use 2149871625L and be happy (I think, haven't tried this).
As it is right now, I cannot use 2.4 at all.
/Slightly/ odd place to mae this report! Hope this mail helped.