On Mon, 21 Nov 2011, Alexander Best wrote:
On Mon Nov 21 11, Alexander Best wrote:
On Mon Nov 21 11, Benjamin Kaduk wrote:
On Mon, 21 Nov 2011, per...@pluto.rain.com wrote:
Alexander Best <arun...@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@
here's a revised patch.
% diff --git a/lib/libc/sys/lseek.2 b/lib/libc/sys/lseek.2
% index 874c523..bcd9d20 100644
% --- a/lib/libc/sys/lseek.2
% +++ b/lib/libc/sys/lseek.2
% @@ -197,13 +196,43 @@ is associated with a pipe, socket, or FIFO.
% The
% .Fn lseek
% system call is expected to conform to
% -.St -p1003.1-90 .
% +.St -p1003.1-2008 .
% +.Pp
% +The
% +.Dv SEEK_HOLE
% +and
% +.Dv SEEK_DATA
% +directives, along with the
% +.Er ENXIO
% +error, are extensions to that specification.
% .Sh HISTORY
% The
% .Fn lseek
% function appeared in
% .At v7 .
% .Sh BUGS
% +If the
% +.Fn lseek
% +system call is operating on a device which is incapable of seeking,
% +it will request the seek operation and return successfully,
% +even though no seek was performed.
% +Because the
% +.Ar offset
% +argument will be stored in the file descriptor of that device,
This sentence assumes more familiarity with file i/o implementation than
seems prudent. Perhaps "stored in the file descriptor of that device and
thus used for future queries" or something similar?
% +there is no way to verifying/falsify the seek operation afterwards
"verifying" is incorrect, here. Just "verify" would work, but the combo
"verify/falsify" doesn't feel quite right.
I guess I want "no way to confirm success of the seek operation" (no
'afterwards').
% +(e.g. using the
% +.Fn ftell
% +function).
% +Device types which are known to be incapable of seeking include
% +tape drives.
"most"? I think someone said that certain (old) drives could actually
seek under some circumstances.
% +.Pp
% +The
% +.Fn lseek
% +system call will not detect, whether media are present in changeable
% +media devices, such as DVD or Blue-ray devices.
The first comma is bogus; the second comma could be removed, and probably
should be.
Also, "Blu-ray" has no 'e' (but apparently is capitalized in that way).
% +A requested seek operation will therefore return sucessfully in case
% +of an uninserted medium.
s/in case of an uninserted medium/when no medium is present/.
Thanks for the fixups,
Ben
% +.Pp
% This document's use of
% .Fa whence
% is incorrect English, but is maintained for historical reasons.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
