From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 21 06:20:56 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0B50106564A; Mon, 21 Nov 2011 06:20:56 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 47B2A8FC14; Mon, 21 Nov 2011 06:20:55 +0000 (UTC) X-AuditID: 12074422-b7ff56d00000092f-46-4ec9edc7aae4 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 3A.CC.02351.7CDE9CE4; Mon, 21 Nov 2011 01:20:55 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id pAL6Kspa023891; Mon, 21 Nov 2011 01:20:54 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id pAL6Kpms022001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Nov 2011 01:20:53 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id pAL6Kp78016534; Mon, 21 Nov 2011 01:20:51 -0500 (EST) Date: Mon, 21 Nov 2011 01:20:51 -0500 (EST) From: Benjamin Kaduk To: arundel@freebsd.org In-Reply-To: <4eca40f5.fvA0Xb1G9w+wuGj6%perryh@pluto.rain.com> Message-ID: References: <20111116102239.GA2687@britannica.bec.de> <20111116131428.GA40723@freebsd.org> <20111116232152.GC21793@britannica.bec.de> <20111117002438.GA55931@freebsd.org> <201111172055.pAHKtZso061118@triton8.kn-bremen.de> <20111118203122.GA9508@freebsd.org> <20111120124034.GA54811@freebsd.org> <20111120140450.GA62286@freebsd.org> <20111120142131.GA64913@freebsd.org> <4eca40f5.fvA0Xb1G9w+wuGj6%perryh@pluto.rain.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixG6nonv87Uk/g0tvFCzaP89jsti++R+j ReO+qywW8zrPMTuweMz4NJ/F48HUDkaP6XuvMwUwR3HZpKTmZJalFunbJXBl9F+TL5jMWdG4 bA5LA+MC9i5GTg4JAROJl4dusUHYYhIX7q0Hsrk4hAT2MUr8+vuZFcLZwCix/sJhKOcAk0T/ gpOMEE4Do8TEF9NYQPpZBLQlDjyZxQhiswmoSMx8sxFsroiAuMTztevAapgF/CROLf8LFhcW cJCY0/CQFcTmFLCT2P/uPjOIzStgL3Hj/GyoO3pYJJp33AUrEhXQkVi9fwoLRJGgxMmZT6CG Wkqc+3OdbQKj4CwkqVlIUgsYmVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmurlZpbopaaUbmIE h7KL0g7GnweVDjEKcDAq8fDOXHnST4g1say4MvcQoyQHk5Iob9oLoBBfUn5KZUZicUZ8UWlO avEhRgkOZiUR3hxnoBxvSmJlVWpRPkxKmoNFSZyXa6eDn5BAemJJanZqakFqEUxWhoNDSYKX HRizQoJFqempFWmZOSUIaSYOTpDhPEDD2UBqeIsLEnOLM9Mh8qcYFaXEeYVBEgIgiYzSPLhe WKp5xSgO9IowLytIFQ8wTcF1vwIazAQ0eNraEyCDSxIRUlINjHbxHOd2L9iu0fRYs4b/8aK1 QmnrHIMav7SsCrqgeMtPN7vx23KeayfPztgh9M3M/HOMzcyjmlvnPNV78fc8b9u+q8tne01/ 7bN6h/hNb2vRd5/t465lZ/62eLOS/YL4yck9SmpfrTUfybgqHHGYeGVBxLW2i6eOrTwv9jPq 8ZOcRfO95whPPuqvxFKckWioxVxUnAgAbSVylRADAAA= Cc: freebsd-hackers@freebsd.org, perryh@pluto.rain.com, nox@jelal.kn-bremen.de Subject: Re: easy way to determine if a stream or fd is seekable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 06:20:56 -0000 On Mon, 21 Nov 2011, perryh@pluto.rain.com wrote: > Alexander Best 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."? -Ben Kaduk