[issue12545] Incorrect handling of return codes in the posix_lseek function in posixmodule.c

Kuberan Naganathan report at bugs.python.org
Sat Jul 23 03:16:32 CEST 2011


Kuberan Naganathan <kubiyak at gmail.com> added the comment:

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" <report at bugs.python.org>
wrote:
>
> Charles-François Natali <neologix at 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/).
>
> 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 <report at bugs.python.org>
> <http://bugs.python.org/issue12545>
> _______________________________________

----------
Added file: http://bugs.python.org/file22721/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12545>
_______________________________________
-------------- next part --------------
<p>yes.  i noticed problem on solaris on the /proc/&lt;pid&gt;/as file which usually has mapped regions beyond 2^63 in most process files</p>
<div class="gmail_quote">On Jul 22, 2011 4:35 PM, &quot;Charles-François Natali&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br type="attribution">&gt; <br>&gt; Charles-François Natali &lt;<a href="mailto:neologix at free.fr">neologix at free.fr</a>&gt; added the comment:<br>
&gt; <br>&gt; Patch attached.<br>&gt; <br>&gt;&gt; For lseek, we can rely on errno. Try something like that:<br>&gt;&gt;<br>&gt;&gt; errno = 0;<br>&gt;&gt; offset = lseek(...);<br>&gt;&gt; if (offset == (off_t)-1 &amp;&amp; errno) /* error */<br>
&gt;&gt;<br>&gt; <br>&gt; It&#39;s a little bit overkill :-) (for mktime, time_t can overflow easily<br>&gt; on 32-bit).<br>&gt; <br>&gt;&gt; We can write a test using a sparse file... Or maybe a mmap object?<br>&gt;&gt;<br>
&gt; <br>&gt; I&#39;m not sure it&#39;s easily testable, because it&#39;s really a corner case<br>&gt; not addressed by POSIX. On my Linux box, I can&#39;t get lseek to return a<br>&gt; negative value, I get EINVAL - which does make sense (the Linux kernel<br>
&gt; doesn&#39;t accept or return negative file offsets, see<br>&gt; <a href="http://lwn.net/Articles/138063/">http://lwn.net/Articles/138063/</a>).<br>&gt; <br>&gt; Kuberan, on what operating system did you notice this problem? Solaris?<br>
&gt; <br>&gt; ----------<br>&gt; keywords: +patch<br>&gt; Added file: <a href="http://bugs.python.org/file22719/lseek_negative.diff">http://bugs.python.org/file22719/lseek_negative.diff</a><br>&gt; <br>&gt; _______________________________________<br>
&gt; Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&gt; &lt;<a href="http://bugs.python.org/issue12545">http://bugs.python.org/issue12545</a>&gt;<br>&gt; _______________________________________<br>
</div>


More information about the Python-bugs-list mailing list