Re: [AD] implementing seek

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On April 7, 2010, Matthew Leverton wrote:
> On Wed, Apr 7, 2010 at 10:04 PM, Peter Wang <novalazy@xxxxxxxxxx> wrote:
> > On 2010-04-07, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> >> Probably like any handle would, except it gets EOF when/after it
> >> reaches the end of the slice. so its impossible to overwrite past the
> >> end.
> > 
> > I was wondering how the user would know how big to make the slice,
> > ahead of time.
> > 
> > Ok, if the al_fopen_slice 'length' parameter is a _maximum_ length,
> > then you can pass INT_MAX or some other big number.  When the slice is
> > closed we set the file position to initial_slice_pos +
> > max_slice_length, or the end of the file, which comes first.
> 
> I haven't thought writing through yet... But my initial thought was
> that the splice is always a well defined length.
> 
> I would think that writing should generally be sequential, and you
> wouldn't need to set up a splice. i.e., Loaders would just happily
> write the contents out start to end, never even trying to seek. As
> such, you could pass the "real" file handle without any issues.
> 
> That said, I suppose it would be naive to assume that.
> 
> A large number is probably better than 0 for indicating arbitrary length.
> 
> One edge case to consider would be what SEEK_END should be on an open
> ended splice ... you have the written length as well as the parent
> file's length.
> 
> e.g.,
> 
> fp = al_fopen(); // file with 10 bytes
> slice = al_fopen_slice(fp, INT_MAX);
> al_fseek(slice, 0, ALLEGRO_SEEK_END);
> 
> Should that go to position 10, or stay at 0, since the slice hasn't
> been written to?

I would have to say 10, since the file already has 10 bytes in it.

> 
> --
> Matthew Leverton
> 
> -------------------------------------------------------------------------
> ----- Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/