From owner-cvs-sys Sat Apr 18 23:05:31 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA20559 for cvs-sys-outgoing; Sat, 18 Apr 1998 23:05:31 -0700 (PDT) (envelope-from owner-cvs-sys) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA20546; Sun, 19 Apr 1998 06:05:20 GMT (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id QAA21960; Sun, 19 Apr 1998 16:03:28 +1000 Date: Sun, 19 Apr 1998 16:03:28 +1000 From: Bruce Evans Message-Id: <199804190603.QAA21960@godzilla.zeta.org.au> To: bde@zeta.org.au, julian@whistle.com Subject: Re: cvs commit: src/lib/libc/sys lseek.2 src/sys/kern vfs_syscalls.c Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, des@FreeBSD.ORG Sender: owner-cvs-sys@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >If this is truely 'common' then that's unfortunate. >what do POSIX and friends have to say about it? Same as usual. On successful completion, the appropriate value is returned. Otherwise, -1 is returned and errno is set to indicate the error. For lseek() the appropriate value is the "offset location as measured in bytes from the beginning of the file". The implementation gets to decided what an error is. The rationale clarifies this in detail for lseek(): "An invalid file offset that would cause EINVAL to be returned may be both implementation defined and device dependent (for example, memory may have few invalid values). A negative file offset may be valid for some devices in some implementations". FreeBSD uses a simple implementation with all negative file offsets valid for all file types. OTOH, for fcntl(), the behaviour is completely undefined if the length of the locked region is negative, and FreeBSD rejects "negative" start and end offsets and negative lengths. This is reasonable because locking is not supported for special files. Bruce