-> > 1067760 -- float-->long conversion on fileobj.seek calls, rather than -> > float-->int. Permits larger floats (2.0**62) to match large -> > int (2**62) arguments. rhettinger marked as "won't fix" in -> > the original bug report; this seems like a clean solution, -> > tho. Recommend apply. -> -> Wouldn't this cause subtle errors when the float -> long conversion is -> no longer precise? Or is this a non issue because it could only happen -> when seeking on impossibly large files?
When would the float --> long conversion not be precise? The docs say PyLong_FromDouble takes the integer part, so it's like doing a floor(), yes?
The current behavior is to convert directly from float to int, even though seek() can take longs as an argument. Thus 2.0**31 works, 2**31 works, 2**62 works, but 2.0**62 doesn't. This seems mildly inconsistent and prompted the guy to submit a bug report, and then a patch.
The patch (with a bit more code context) is:
-- if (!PyArg_ParseTuple(args, "O|i:seek", &offobj, &whence)) return NULL;
#if !defined(HAVE_LARGEFILE_SUPPORT) offset = PyInt_AsLong(offobj); #else + if(PyFloat_Check(offobj)) { + offobj = PyLong_FromDouble(PyFloat_AsDouble(offobj)); + } offset = PyLong_Check(offobj) ? PyLong_AsLongLong(offobj) : PyInt_AsLong(offobj); #endif --
so the issue only comes into play with large file support.
Heh, and I just noticed that PyLong_FromDouble returns a new reference, so this is a memory leak, I believe. Whoooops. I'll fix that.
cheers, --titus