[Python-Dev] Patches: 1 for the price of 10.

[Titus Brown]

-> > 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