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