Date: Thu, 9 Sep 1999 02:50:02 -0700 (PDT) From: <jkoshy@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/6184: No error if resulting file pos in lseek is negative Message-ID: <199909090950.CAA89283@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/6184; it has been noted by GNATS.
From: <jkoshy@FreeBSD.org>
To: Dag-Erling Smorgrav <des@flood.ping.uio.no>
Cc: FreeBSD-gnats-submit@freebsd.org, phk@freebsd.org,
bde@freebsd.org
Subject: Re: kern/6184: No error if resulting file pos in lseek is negative
Date: Thu, 9 Sep 1999 02:42:26 -0700 (PDT)
> There's a reason why I didn't commit that patch - I don't remember the
> details, but I vaguely recall someone convincing me that returning an
> error was not necessarily the right thing. It's been so long I'd have
> to search the archives to find out for sure.
As it stands, the patch is not correct because we need to be able to lseek
to half-way of a 64 bit address range after opening /dev/[k]mem.
POSIX allows negative file offsets for special devices.
{ISO/IEC 9945-1:1996 Rationale [B.6.5.3]}.
OpenBSD solves this problem by allowing negative file offsets if the
file descriptor refers to a character device. NetBSD has a VOP_SEEK()
operation and defers checking of the validity of the offset to its
lower layers. IMO, the NetBSD way is correct because EINVAL is supposed to
be returned if an 'invalid offset' results from the attempted lseek(), and
different filesystems can have different 'invalid offsets'.
For now I'm testing a simple version which checks for character
devices and allows negative offsets.
Regards,
Koshy
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?199909090950.CAA89283>