Well, as stated, you can just compute that by yourself without the parameter. Look at the code on SO.com again -- it *does* use the parameter -- it uses it to compute the final position.<br><br>I&#39;m not the maintainer of the library, but I think it would be a *very* bad idea to add a redundant feature for something which can be gotten around so easily.<br>
<br>And since fseek() cannot work with negative indices, why should this? I don&#39;t see why it couldn&#39;t be so simple (or even simpler -- ignore this case as it won&#39;t happen anyways).<br>In either case, what should be read anyways if you try to seek at, say, file position -10? 0x00? 0xFF? EOF? ... there&#39;s a reason why fseek() cannot work with that.<br>
<br>On top of the API change problems, you&#39;d also add dangerous portability problems if SEEK_* constants are defined differently for the lib and the program using it.<br><br><div class="gmail_quote">On 3 December 2012 19:37, fy <span dir="ltr">&lt;<a href="mailto:fy0748@gmail.com" target="_blank">fy0748@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>


<div>在 Tue, 04 Dec 2012 00:27:45 +0800,Tim Čas &lt;<a href="mailto:darkuranium@gmail.com" target="_blank">darkuranium@gmail.com</a>&gt; 写道:<div class="im"><br><br><blockquote style="margin:0 0 0.80ex;border-left:#0000ff 2px solid;padding-left:1ex">
One more thing, which I forgot to mention...<br><br>... I don&#39;t know whether seeking w/ fseek before the start of file is implementation-defined or straight out undefined. In either case, the Vorbis API should not be doing the former because of portability concerns, and should not be doing the latter because, well, it&#39;s undefined.<br>

<br>If it&#39;s the former (impl-defined) and you&#39;re feeling paranoid, you can always just do the thing I&#39;ve specified in the previous email -- what&#39;s important is that it&#39;s consistent.<br>If it&#39;s the latter (undefined), you don&#39;t need to worry about handling it at all, since for all the standard cares, it could summon (in the case of fseek) nasal demons.<br>

<br>That&#39;s in theory anyways -- in practice, as stated, I highly doubt the API would do such a nasty thing due to the aforementioned reasons.</blockquote><div><br></div></div><div>OK. Now I tired, but failed.</div><div>
<br></div><div>Then I load whole file into memory.I got a record of func calls by codes of stackoverflow :</div><div><br></div><div>SEEK_END<br>SEEK_END<br>SEEK_SET<br>SEEK_SET</div><div><br></div><div>The &quot;fromwhere&quot; parameter is REALLY needed.</div>
<div><br></div><div><br></div><div>As to this code snippet,</div><div class="im"><div><br></div><div>&gt; if(type == SEEK_CUR)<br>&gt; {<br>&gt; if(pos &lt; -diff) // in other words, if `pos + diff` would be negative<br>&gt; pos = 0;<br>
&gt; else<br>&gt; pos += diff;<br>&gt; }</div><div><br></div></div><div>It can&#39;t be so easy.</div><div><br></div><div><br></div><div>Anyway the problem is solved, not in the best way.</div><div><br></div><div>So I think it should be patched.</div>
<div><br></div><div><br></div><div><div>-- </div><div>使用Opera的电子邮件客户端:<a href="http://www.opera.com/mail/" target="_blank">http://www.opera.com/mail/</a></div></div></div><br>_______________________________________________<br>

physfs mailing list<br>
<a href="mailto:physfs@icculus.org">physfs@icculus.org</a><br>
<a href="http://icculus.org/mailman/listinfo/physfs" target="_blank">http://icculus.org/mailman/listinfo/physfs</a><br>
<br></blockquote></div><br>