Date: Sun, 19 Apr 1998 16:03:28 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, julian@whistle.com Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-lib@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, des@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/sys lseek.2 src/sys/kern vfs_syscalls.c Message-ID: <199804190603.QAA21960@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804190603.QAA21960>