Date: Wed, 1 Apr 1998 17:57:38 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.ORG, kent@erlang.ericsson.se Subject: Re: lseek bug? Message-ID: <199804010757.RAA06072@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>In FreeBSD 2.2.5 lseek moves the file position without any error >checks. If the resulting position is negative we have the problem that >the result value -1 can mean two things, that there was an error or >that the file position was set to -1 and no error. We have to clear >errno before the call and examine errno after the call to find out if >there was an error or not. > >If the resulting position is to be negative, Linux and Solaris will >preserve the file position before the call to lseek and return an >error. > >Is this a bug in FreeBSD or a different interpretations of the POSIX >standard? This is lack of support for negative offsets on some systems. POSIX.1-1990 specifies that upon successful completion, lseek() returns the offset in bytes from the beginning of the file. It's not clear whether negative offsets are allowed. However, the rationale make it clear that they were intended to be allowed: "A negative file offset may be valid for some devices in some implementations". FreeBSD allows negative offsets (including -1) for all devices and files. In FreeBSD-1.x, this was necessary for seeking to kernel addresses in /dev/kmem on 32-bit systems. Perhaps it will be necessary for seeking to kernel addresses in /dev/kmem on 64-bit systems. In any case, portable POSIX programs (if any) need to set and check errno as you mention above if the result upon successful completion may be (off_t)-1. If the result may be negative but not (off_t)-1, then all they have to do is check for (off_t)-1 and not for < 0. The POSIX Conformance Test Suite gets this wrong (at least if it is testing plain POSIX.1-1990) by assuming that some negative offsets (perhaps only -1) can't be seeked to. There are similar complications for read() and write(). The results of writing "negative" sizes are implementation defined, but sometimes useful... Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804010757.RAA06072>