[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c
New submission from Kuberan Naganathan : The lseek function can legitimately return a code less then zero ( except for -1 ) when seeking beyond an offset of 2^63. This behavior should be supported in order to permit the python interpreter to seek in files with valid data at locations greater than or equal to 2^63. This can happen in a sparse file or in the /proc file system address space file. The fix is simple. In the posix_lseek function check for result != -1 instead of checking for result < 0 in return code checks of the value returned by lseek. -- components: IO messages: 140222 nosy: Kuberan.Naganathan priority: normal severity: normal status: open title: Incorrect handling of return codes in the posix_lseek function in posixmodule.c versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue12545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c
Kuberan Naganathan added the comment: In addition I would like the posix_lseek function to accept a value larger than 2^63 as a seek offset. Currently I seem to need to seek multiple times within a file to achieve an offset larger than 2^63 ( assuming the return type check on the return value of lseek is fixed. ) -- ___ Python tracker <http://bugs.python.org/issue12545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c
Kuberan Naganathan added the comment: Im most familiar with solaris. Atleast on solaris lseek interprets its signed arg as the unsigned value with the same bit pattern. I cannot be certain that this is common across other operating systems. On Jul 13, 2011 8:09 AM, "Antoine Pitrou" wrote: > > Antoine Pitrou added the comment: > >> In addition I would like the posix_lseek function to accept a value >> larger than 2^63 as a seek offset > > How would it work? The C lseek() takes a signed (64-bit) offset as argument, so we would have to call it multiple times anyway. > > -- > nosy: +neologix, pitrou > versions: +Python 3.2, Python 3.3 > > ___ > Python tracker > <http://bugs.python.org/issue12545> > ___ -- Added file: http://bugs.python.org/file22641/unnamed ___ Python tracker <http://bugs.python.org/issue12545> ___Im most familiar with solaris. Atleast on solaris lseek interprets its signed arg as the unsigned value with the same bit pattern. I cannot be certain that this is common across other operating systems. On Jul 13, 2011 8:09 AM, "Antoine Pitrou" <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote:> > Antoine Pitrou <mailto:pit...@free.fr";>pit...@free.fr> added the comment: > >> In addition I would like the posix_lseek function to accept a value>> larger than 2^63 as a seek offset> > How would it work? The C lseek() takes a signed (64-bit) offset as argument, so we would have to call it multiple times anyway. > > --> nosy: +neologix, pitrou> versions: +Python 3.2, Python 3.3> > ___> Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> > <http://bugs.python.org/issue12545";>http://bugs.python.org/issue12545>> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c
Kuberan Naganathan added the comment: I did some testing on this. Solaris seems to treat files as a large circular buffer of size 2^64 with respect to seeks in the /proc file system address space file. No error results with seeks of greater than 2^63 with any of SEEK_SET, SEEK_CUR, SEEK_END. This is not true of a regular file where I get errno=22 when seeking to an offset greater than or equal to 2^63. So even on solaris the behavior seems to be filesystem dependent. -- Added file: http://bugs.python.org/file22645/unnamed ___ Python tracker <http://bugs.python.org/issue12545> ___I did some testing on this. Solaris seems to treat files as a large circular buffer of size 2^64 with respect to seeks in the /proc file system address space file. No error results with seeks of greater than 2^63 with any of SEEK_SET, SEEK_CUR, SEEK_END. This is not true of a regular file where I get errno=22 when seeking to an offset greater than or equal to 2^63. So even on solaris the behavior seems to be filesystem dependent. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c
Kuberan Naganathan added the comment: Hi. I can submit a patch for the first part. Should I submit on this issue tracker item? -- ___ Python tracker <http://bugs.python.org/issue12545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c
Kuberan Naganathan added the comment: Hi. I'm unable ( or have to jump through lots of hoops ) to submit this patch myself for regulatory reasons. Can someone else submit this please? Thanks. -- ___ Python tracker <http://bugs.python.org/issue12545> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c
Kuberan Naganathan added the comment: yes. i noticed problem on solaris on the /proc//as file which usually has mapped regions beyond 2^63 in most process files On Jul 22, 2011 4:35 PM, "Charles-François Natali" wrote: > > Charles-François Natali added the comment: > > Patch attached. > >> For lseek, we can rely on errno. Try something like that: >> >> errno = 0; >> offset = lseek(...); >> if (offset == (off_t)-1 && errno) /* error */ >> > > It's a little bit overkill :-) (for mktime, time_t can overflow easily > on 32-bit). > >> We can write a test using a sparse file... Or maybe a mmap object? >> > > I'm not sure it's easily testable, because it's really a corner case > not addressed by POSIX. On my Linux box, I can't get lseek to return a > negative value, I get EINVAL - which does make sense (the Linux kernel > doesn't accept or return negative file offsets, see > http://lwn.net/Articles/138063/). > > Kuberan, on what operating system did you notice this problem? Solaris? > > -- > keywords: +patch > Added file: http://bugs.python.org/file22719/lseek_negative.diff > > ___ > Python tracker > <http://bugs.python.org/issue12545> > ___ -- Added file: http://bugs.python.org/file22721/unnamed ___ Python tracker <http://bugs.python.org/issue12545> ___yes. i noticed problem on solaris on the /proc/<pid>/as file which usually has mapped regions beyond 2^63 in most process files On Jul 22, 2011 4:35 PM, "Charles-François Natali" <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote:> > Charles-François Natali <mailto:neolo...@free.fr";>neolo...@free.fr> added the comment: > > Patch attached.> >> For lseek, we can rely on errno. Try something like that:>>>> errno = 0;>> offset = lseek(...);>> if (offset == (off_t)-1 && errno) /* error */ >>> > It's a little bit overkill :-) (for mktime, time_t can overflow easily> on 32-bit).> >> We can write a test using a sparse file... Or maybe a mmap object?>> > > I'm not sure it's easily testable, because it's really a corner case> not addressed by POSIX. On my Linux box, I can't get lseek to return a> negative value, I get EINVAL - which does make sense (the Linux kernel > doesn't accept or return negative file offsets, see> http://lwn.net/Articles/138063/";>http://lwn.net/Articles/138063/).> > Kuberan, on what operating system did you notice this problem? Solaris? > > --> keywords: +patch> Added file: http://bugs.python.org/file22719/lseek_negative.diff";>http://bugs.python.org/file22719/lseek_negative.diff> > ___ > Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org>> <http://bugs.python.org/issue12545";>http://bugs.python.org/issue12545>> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
