[physfs] PHYSFS_seek is too simple

fy fy0748 at gmail.com
Mon Dec 3 21:25:26 EST 2012


在 Tue, 04 Dec 2012 02:42:38 +0800,Tim Čas <darkuranium at gmail.com> 写道:

> 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.
>
> I'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.
>
> And since fseek() cannot work with negative indices, why should this? I  
> don't see why it couldn't be so >simple (or even simpler -- ignore this  
> case as it won't happen anyways).
> In either case, what should be read anyways if you try to seek at, say,  
> file position -10? 0x00? 0xFF? >EOF? ... there's a reason why fseek()  
> cannot work with that.
>
> On top of the API change problems, you'd also add dangerous portability  
> problems if SEEK_* constants are >defined differently for the lib and  
> the program using it.

I can't agree with you about the reason why fseek() cannot work with  
negative indices.

The max length of a file equals max value of uint64, unsigned int.

fseek() use uint64 means you can go to any position you want from the  
start of file.

The sign bit is not exist in uint64.

So if you pass a negative number to the function, you will get a overflow.

And the result of compute will be always a positive number, no matter  
overflowed or not.

The "fromwhere" will be always SEEK_CUR in fact.


Maybe I don't understand yours actually means, but in my opinion, pos can  
not be a  negative number, so I can't seek data by SEEK_SET.


-- 
使用Opera的电子邮件客户端:http://www.opera.com/mail/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20121204/526da51d/attachment-0001.htm>


More information about the physfs mailing list