En Mon, 17 Dec 2007 10:30:05 -0300, Nick Craig-Wood <[EMAIL PROTECTED]> escribió:
> Gabriel Genellina <[EMAIL PROTECTED]> wrote: >> En Sun, 16 Dec 2007 20:28:02 -0300, Troels Thomsen <"nej >> tak..."@bag.python.org> escribi?: >> >> > >> > The readFile function from the win32 package aparently really expect >> an >> > integer : >> > >> > def inWaiting(self): >> > """Returns the number of bytes waiting to be read""" >> > flags, comstat = ClearCommError(self.__handle) >> > return comstat.cbInQue >> > >> > ReadFile(h, s.inWaiting()) >> > >> > My code crashes because inWaiting returns a long, not an int >> >> That's very strange. The cbInQue field is a DWORD in C, seen as an int >> in >> Python. How do you know it returns a long? >> >> > Why is that different on my machine and my collegues ? Have I or he >> > installed a wrong version of a package? >> > CPython 2.5. >> >> And pywin32 build 210, I presume. >> >> > Was not expecting int<->long type problems in excactly python >> language. >> > Is that because we are navigating so close to the win32 api that the >> > types >> > are more strictly enforced ? >> >> Somewhat. At the API level, function arguments have to be converted to >> native C types, like ReadFile expecting a DWORD. Any number greater >> than >> 2**32 won't fit, but I can't think how such thing could happen looking >> at >> those few posted code lines. > > Actually any number >= 2**31 won't fit in a python int. > > >>> 2**31 > 2147483648L > > According to my headers DWORD is defined like this > > typedef unsigned long DWORD; > > So you might see longs returned when you expected ints if the result > was >= 0x8000000. More than 2GB waiting to be read from a serial port? If that were the case the OP has a very big throughput problem rather than an API mismatch :) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
