From owner-freebsd-bugs  Wed Apr  1 00:00:21 1998
Return-Path: <owner-freebsd-bugs@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id AAA07437
          for freebsd-bugs-outgoing; Wed, 1 Apr 1998 00:00:21 -0800 (PST)
          (envelope-from owner-freebsd-bugs@FreeBSD.ORG)
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 AAA07425
          for <freebsd-bugs@FreeBSD.ORG>; Wed, 1 Apr 1998 00:00:16 -0800 (PST)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id RAA06072;
	Wed, 1 Apr 1998 17:57:38 +1000
Date: Wed, 1 Apr 1998 17:57:38 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199804010757.RAA06072@godzilla.zeta.org.au>
To: freebsd-bugs@FreeBSD.ORG, kent@erlang.ericsson.se
Subject: Re: lseek bug?
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

>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