easy way to determine if a stream or fd is seekable

Alexander Best arundel at freebsd.org
Mon Nov 21 11:02:07 UTC 2011


On Mon Nov 21 11, Benjamin Kaduk wrote:
> On Mon, 21 Nov 2011, perryh at pluto.rain.com wrote:
> 
> >Alexander Best <arundel at freebsd.org> wrote:
> >
> >>here's a revised patch.
> >>...
> >>+.Sh CAVEATS
> >>+If the
> >>+.Fn lseek
> >>+system call is operating on a device, which is incapable of seeking,
> >>+it will request the seek operation and complete successfully.
> >
> >I think it would be better without the first comma (after "device").
> 
> Definitely.
> 
> Also,
> 
> +.Sh CAVEATS
> +If the
> +.Fn lseek
> +system call is operating on a device, which is incapable of seeking,
> +it will request the seek operation and complete successfully.
> 
> I would prefer something like "request the seek operation and return as if 
> the seek was successful, even though no seek was performed."
> 
> +The value of the pointer associated with such a device is undefined.
> 
> "Which pointer?"  That it is "the file offset" was clear from context 
> where this line was moved from, but is no longer, here.
> 
> +Device types which can be incapable of seeking include,
> +but are not limited to, tape drives.
> 
> This is an awkward phrasing; perhaps just "Many tape drives are incapable 
> of seeking and can trigger this bug."?

this is too limited. this suggests that only certain tape drives won't seek
after a successfull return of lseek(). as i mentioned beforehand, this is also
the case with device with insertable media, such as dvd and blue-ray drives.
here lseek() will sucessfully return, without a media inserted.

i'll rephrase the whole patch and will submit a revised version. i think a
reference to POLA, would also be a good idea, as suggested by perry@

thanks for all the suggestions.

cheers.
alex

> 
> -Ben Kaduk


More information about the freebsd-hackers mailing list