-> > 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
